1. 关于waitpid
A fork B, B中的b0 通过pthread_create b1
A waitpid (B) b0 pthread_join(b1)
b0,b1的ppid都是A
b1的gpid是b0
如果b1退出，则b1通过do_exit进入Z，等待b0通过pthread_join回收
如果b0退出，则A waitpid被唤醒，遍历b0,b1的状态，发现b1不是Z，b0是Z，
而b0是领头线程，不会回收
waitpid流程分析：
kernel/exit.c
SYSCALL_DEFINE5(waitid, int, which, pid_t, upid, struct siginfo __user *,
infop, int, options, struct rusage __user *, ru)
{
do_wait();
}
static long do_wait(struct wait_opts *wo)
{
//初始化父进程的等待个体child_wait
init_waitqueue_func_entry(&wo->child_wait, child_wait_callback);
//该个体对应当前进程
wo->child_wait.private = current;
//将child_wait加到当前进程的wait_chldexit等待队列里。后续可能
// current进程被切换出去，再被其他进程通过signal->wait_chldexit
//来唤醒
add_wait_queue(¤t->signal->wait_chldexit, &wo->child_wait);
//schedule时可以摘除
set_current_state(TASK_INTERRUPTIBLE);
do {
retval = do_wait_thread(wo, tsk);
if (retval)
goto end;
retval = ptrace_do_wait(wo, tsk);
if (retval)
goto end;
if (wo->wo_flags & __WNOTHREAD)
break;
} while_each_thread(current, tsk);
其中，
#define while_each_thread(g, t) \
while ((t = next_thread(t)) != g) 即遍历所有和tsk同组的线程
}
2. 关于dropcache， 最后会将“干净的”page cache回收
3. 关于文件系统学习。
4. cache mips
4路组相连，cache size 32k，cache line 16 bytes
那么就是4行cache line为一组，总共有32k / (4*32) = 512组
关于cache指令
HIT操作：先用addr的bit4-bit12组选，再尝试用bit31-bit15的va经过tlb得到pa，与组内的tag同时匹配，
如果匹配，则命中(HIT)，执行cache后的行操作，否则什么都不做。
疑问，tag就是物理地址的bit31-bit15？
还有一种操作，是index访问。在组算后，不经过TLB，直接用地址的bit14-bit13进行组内索引。主要是用在不需要
刷新物理地址的场合。如内核空间的虚拟地址刷新。同时，为了避免寻址的问题，待index刷新的地址，需要是
unmapped区域。
关于引起cache aliase的终极解释：
什么是cache aliase？ 就是同一个物理地址，对应着2个的虚拟地址，而这2个虚拟地址，分别在不同的cache
组里。造成同步的问题。
为什么会形成这种现象？ 因为，如果两个虚拟地址对应的物理地址相同，那么虚拟地址的低12位，一定相同，
而bit12-bit31一定不同。
在VIPT的cache结构中，抽取bit 2 - bit11作为虚拟地址index的话，那么一定会映射到同一个组，不会引起cache
aliase，如果抽取bit 2 - bit 12，而bit12不相同的话，则映射到不同的组，引起cache aliase问题。
因此问题的根源在于，你设置的内核页面是多大？是否比抽取的虚拟地址低n位（就是way size）大？大的话，则不会有cache aliase
，所以尽量把内核的页面设置的比较大就对了。
5. 伙伴系统判断内存是否够用的__zone_watermark_ok
if (free_pages <= min + z->lowmem_reserve[classzone_idx])
return 0;
for (o = 0; o < order; o++) {
/* At the next order, this order's pages become unavailable */
free_pages -= z->free_area[o].nr_free << o;
/* Require fewer higher order pages to be free */
min >>= 1;
if (free_pages <= min)
return 0;
}
判断的思路是：
5.1) 如果本次分配order的页面，即1<<order个页面， 那么剩下的页面要大于水线加上保留页面的个数
5.2) 如果5.1检查通过了还没完，还要保证，这剩下的页面，可以给剩下的阶，从0 到 order -1， 依次尝试分配完后，每次都还有一定富余的页面。
通俗的讲，就是 free_pages = o[0] + o[1] +...+o[order]+...+o[11] - o[order]
首先判断free+pages是否大于min，
接着判断free_pages - o[0] 是否大于 min/2
在判断free_pages - o[1] 是否大于min/4
最后判断free_pages-o[order-1]是否大于min/2*(order-1)
为什么要这么判断？
6. rtmutex try_to_steal_lock(lock)
尝试将一个处于pending 状态的owner的锁偷取
疑问是，next = rt_mutex_top_waiter(lock); 这里是取当前锁阻塞住的最高优先级对象，
将此对象从
7. cmpxchg %ecx, %ebx；如果EAX与EBX相等，则ECX送EBX且ZF置1；否则EBX送EAX，且ZF清0
8.
mips64 xlp
pte entry
低6位是给软件用，如_PAGE_DIRTY ，低6位的操作由宏_PAGE_GLOBAL_SHIFT来控制
#define _PAGE_GLOBAL_SHIFT 6
接下来的bit就是和entry low一一对应。
如gloabal 位
#define _PAGE_GLOBAL (1 << _PAGE_GLOBAL_SHIFT)
valid位
#define _PAGE_VALID_SHIFT (_PAGE_GLOBAL_SHIFT + 1)
以及我们关注的3个C位
#define _CACHE_SHIFT (_PAGE_DIRTY_SHIFT + 1)
#define _CACHE_MASK (7 << _CACHE_SHIFT)
#define _PFN_SHIFT (PAGE_SHIFT - 12 + _CACHE_SHIFT + 3)
这个_PFN_SHIFT为什么会和PAGE_SHIFT搅在一起？我们来看xlp里关于entry low的pfn位(bit6-bit33)
的解释:The PFN field corresponds to bits 35:12 of the physical address
即是说，entry low里的pfn保存的是以4k为大小的页帧号，而pte entry里保存的却是按实际页大小计算
出来的页帧号，所以需要左移相应的位数，写到entry low的pfn字段里。
hello
关于int check_tlb_info(unsigned long vaddr)函数的一点疑问，此处我觉得可能会造成tlb漏打：
这个函数里，判断虚拟地址与tlb条目是否匹配的条件是：
unsigned long vaddr_entry = vaddr&(~0x1fffUL);
if(vaddr_entry == (entryhi & ~0x1fffUL))
即去掉entryhi里bit0 - bit 12后，与虚拟地址的相应位做比较。
我的理解是，此比较的前提是内核采用4k页面。
当系统采用16k页面时，还应该考虑pagemask的相应位：（见see mips run 6.2 节）
也就是说，判断我觉得应该改为：
unsigned long vaddr_entry = vaddr&(~0x7fffUL);
if(vaddr_entry == (entryhi & ~0x7fffUL))
这样才不会漏打tlb。
例如：
在16k页面的系统里，
vaddr:0x120003bf0
entry:0x12000002d
如果只掩掉低13位，他们是不相等的；
但如果掩掉低15位，他们是相等的，也就是此tlb entry实际上是匹配vaddr虚拟地址的。
当在ade异常里，又发生tlb miss怎么办？
因为exl = 1， 所以会进tlbl异常。在build_r4000_tlb_load_handler里，
首先通过build_r4000_tlbchange_handler_head得到出问题地址所在的页表项pte
并检查是否有效build_pte_present(&p, &r, K0, K1, label_nopage_tlbl);
如果没有_PAGE_PRESENT标志，则跳转至后面nopage_tlbl标记处，并进入do_page_fault；
如果有_PAGE_PRESENT标志，则通过build_r4000_tlbchange_handler_tail将pte设置到tlb entry里。
具体写到哪个tlb entry？ 根据虚拟地址probe找到匹配的tlb条目。如果没有匹配的，就通过
random写入。同时，在page_fault流程里，一旦走到最后的handle_pte_fault，进入__update_tlb，
也是先根据虚拟地址probe，找得到就write_index_tlb，找不到就 write_random_tlb
9. 缺页流程里，handle_mm_fault，首先是pmd_alloc，pte_alloc_map检查是否存在对应的页表，没有就分配，
最后传入对应的pte entry的指针，和上一层指向pte表的 pmd entry指针
handle_pte_fault(mm, vma, address, pte, pmd, flags);
重新获取pte entry指针的地址，并加锁
page_table = pte_offset_map_lock(mm, pmd, address, &ptl);
将pte entry设置到条目里
set_pte_at(mm, address, page_table, entry);
对于mips来说，update_mmu_cache会更新相应的tlb entry并刷一下cache
先是__update_tlb里，会根据地址查找tlb entry，找得到的话就更新至此tlb，找不到就更新到一个random的tlb
对于__update_cache来说，则按L1_CACHE_BYTES，循环刷dcache， 直到刷满一页。