diff --git a/.DS_Store b/.DS_Store
index 18b94aa..6b3f9ca 100644
Binary files a/.DS_Store and b/.DS_Store differ
diff --git a/README.md b/README.md
index ae1e909..f2863a8 100644
--- a/README.md
+++ b/README.md
@@ -41,7 +41,7 @@ Kubernetes这一整个项目颇为庞大，一般情况下，如果熟悉kuberne
 
 
 
-### 参考
+## 参考
 1.官方开发者向导md文档: https://github.com/kubernetes/community/tree/master/contributors/devel
 
 2.http://hutao.tech/k8s-source-code-analysis/
diff --git a/scheduler/Kubernetes源码学习-Scheduler-P1-调度器入口篇.md b/scheduler/Kubernetes源码学习-Scheduler-P1-调度器入口篇.md
index 7b21658..d8992bf 100644
--- a/scheduler/Kubernetes源码学习-Scheduler-P1-调度器入口篇.md
+++ b/scheduler/Kubernetes源码学习-Scheduler-P1-调度器入口篇.md
@@ -142,7 +142,7 @@ delete pods: pod1
 
 ```
 
-#### 看到这里，相信对cobra的强大简洁已经有了初步的认知，建议自行进入项目主页了解详情并进行安装测试
+** 看到这里，相信对cobra的强大简洁已经有了初步的认知，建议自行进入项目主页了解详情并进行安装测试**
 
 ## 入口
 通过对上方cobra的基本了解，我们不难知道，`cmd/kube-scheduler/scheduler.go`内的main()方法内部实际调用的是`cobra.Command.Run`内的匿名函数，我们可以进入`NewSchedulerCommand()`内部确认:
@@ -181,8 +181,15 @@ Broadcaster     record.EventBroadcaster
 ![image](http://pwh8f9az4.bkt.clouddn.com/scheRun.jpg)
 
 `wait.Until`这个调用的逻辑是，直到收到stop信号才终止，在此之前循环运行`sched.scheduleOne`。代码走到这里，终于找到启动入口最内部的主体啦:
-![image](http://pwh8f9az4.bkt.clouddn.com/scheduleOne.jpg)
 
-`sched.scheduleOne`这个函数有代码点长，整体的功能可以概括为:获取需调度的pod、寻找匹配node、发起绑定到node请求、绑定检查等一系列操作.
+![](http://pwh8f9az4.bkt.clouddn.com/image-20190827163439895.png)
 
-#### 本篇入口篇到这里就先告一段落，下一篇开始阅读学习调度过程的逻辑！
+`sched.scheduleOne`这个函数有代码点长，整体的功能可以概括为:
+
+1.获取需调度的pod
+
+2.使用调度算法寻找匹配node、发起绑定到node请求、绑定检查等一系列操作.
+
+3.若匹配node失败，则尝试根据pod的指定优先级来抢占资源
+
+**本篇入口篇到这里就先告一段落，下一篇开始阅读学习调度过程的逻辑！**
diff --git a/scheduler/Kubernetes源码学习-Scheduler-P3-Node筛选算法.md b/scheduler/Kubernetes源码学习-Scheduler-P3-Node筛选算法.md
index b4dfb00..60c3e67 100644
--- a/scheduler/Kubernetes源码学习-Scheduler-P3-Node筛选算法.md
+++ b/scheduler/Kubernetes源码学习-Scheduler-P3-Node筛选算法.md
@@ -10,6 +10,8 @@
 
 ## 正文
 
+### 筛选算法入口
+
 Schedule()的筛选算法核心是`findNodesThatFit()`方法 ,直接跳转过去:
 
 `pkg/scheduler/core/generic_scheduler.go:184` --> `pkg/scheduler/core/generic_scheduler.go:435`
@@ -80,7 +82,9 @@ func (g *genericScheduler) findNodesThatFit(pod *v1.Pod, nodes []*v1.Node) ([]*v
 }
 ```
 
-这里一眼就可以看出核心匿名函数内的主体是`podFitsOnNode()`,但是并不是直接执行`podFitsOnNode()`函数，而是又封装了一层函数，这个函数的作用是在外层使用`nodeName := g.cache.NodeTree().Next()`来获取要判断的node主体，传递给`podFitsOnNode()`函数，而后对`podFitsOnNode`函数执行返回的结果进行处理。着眼于其下的并发处理实现:`workqueue.ParallelizeUntil(ctx, 16, int(allNodes), checkNode)`,就可以理解这样封装的好处了,来看看并发实现的内部吧:
+这里一眼就可以看出核心匿名函数内的主体是`podFitsOnNode()`,但是并不是直接执行`podFitsOnNode()`函数，而是又封装了一层函数，这个函数的作用是在外层使用`nodeName := g.cache.NodeTree().Next()`来获取要判断的node主体，传递给`podFitsOnNode()`函数，而后对`podFitsOnNode`函数执行返回的结果进行处理。着眼于其下的并发处理实现:`workqueue.ParallelizeUntil(ctx, 16, int(allNodes), checkNode)`,就可以理解这样封装的好处了,来看看并发实现的内部吧
+
+### 并发控制
 
 `vendor/k8s.io/client-go/util/workqueue/parallelizer.go:38`
 
@@ -231,11 +235,11 @@ func podFitsOnNode(
 
 图中`pkg/scheduler/core/generic_scheduler.go:608`位置正式开始了逐个计算筛选算法，那么筛选方法、筛选方法顺序在哪里呢？在上一篇[P2-框架篇]([https://github.com/yinwenqin/kubeSourceCodeNote/blob/master/scheduler/P2-%E8%B0%83%E5%BA%A6%E5%99%A8%E6%A1%86%E6%9E%B6.md](https://github.com/yinwenqin/kubeSourceCodeNote/blob/master/scheduler/P2-调度器框架.md))中已经有讲过，默认调度算法都在`pkg/scheduler/algorithm/`路径下，我们接着往下看.
 
-**Predicates Ordering / Predicates  Function**
+### Predicates  Function
 
 筛选算法相关的`key/func/ordering`，全部集中在`pkg/scheduler/algorithm/predicates/predicates.go`这个文件中
 
-**筛选顺序**:
+#### 筛选顺序
 
 `pkg/scheduler/algorithm/predicates/predicates.go:142`
 
@@ -258,7 +262,7 @@ var (
 
 ![](http://pwh8f9az4.bkt.clouddn.com/predicates.jpg)
 
-**筛选key**
+#### 筛选key
 
 ```go
 const (
@@ -339,7 +343,7 @@ const (
 )
 ```
 
-**筛选Function**
+#### 筛选Function
 
 每个`predicate key`对应的`function name`一般为`${KEY}Predicate`,function的内容其实都比较简单,不一一介绍了，自行查看，这里仅列举一个:
 
@@ -371,7 +375,7 @@ func CheckNodeMemoryPressurePredicate(pod *v1.Pod, meta PredicateMetadata, nodeI
 
 筛选算法过程到这里就已然清晰明了！
 
-### 重点回顾
+## 重点回顾
 
 筛选算法代码中的几个不易理解的点(亮点?)圈出: