为了较快的从给定的pid值得到相应的宿主结构（进程描述符）指针，内核采用了pid哈希链表结构。
首先，以下的问题要理解：
1）为什么pid哈希链表只定义2048或者4096项（根据你的内存大小确定）？直接定义为pid最大值不是最好吗？
我们都知道，查找的最快方式就是数组了，可以在常数的时间内完成查找。假如我们的pid最大值为32768，那么我们完全可以定义一个struct task_struct* name[32768];进而可以最快速的从给定的pid值中找到其相应的宿主结构。也就是指向该pid进程的进程描述符指针。
然而，这确实一种不理智的方法。虽然进程PID的最大值为32768，但是，我们在实际应用中所能用的pid值要平均值要远远低于这个值。这样的话，会造成大量的物理空间浪费。假如我们用到了2768个pid，那么还有30000*4bytes的空间浪费。
2）特殊情况的需求
设想这样一种情况：假设内核必须回收一个给定pid值的线程组内的所有线程，（线程组内的所有线程的pid值都是相同的）在上述数组形式的定义中，是无法完成的。
而我们要做的是必须为这种形式的线程组（pid值相同）组织成一个链表。这个链表的节点，就是这个线程组内的全部线程。
而pid哈希链表能很好的完成上述的1）2）两点。
下面我们看一下内核对pid哈希链表的定义和初始化过程以及相关的操作。
static struct hlist_head *pid_hash[PIDTYPE_MAX];
系统在初始化期间手动的创建了一个含有PIDTYPE_MAX个元素的指针数组。
用于存放指向hash桶的指针。
并且在start_kernel期间调用pidhash_init函数对hash桶进行初始化。
303 void __init pidhash_init(void)
/* */
304 {
305 int i, j, pidhash_size;
306 unsigned long megabytes = nr_kernel_pages >> (20 - PAGE_SHIFT);
307
308 pidhash_shift = max(10, fls(megabytes * 4));
309 pidhash_shift = min(12, pidhash_shift);
310 pidhash_size = 1 << pidhash_shift;
311
312 printk("PID hash table entries: %d (order: %d, %Zd bytes)\n",
313 pidhash_size, pidhash_shift,
314 PIDTYPE_MAX * pidhash_size * sizeof(struct hlist_head));
315 #######以上为桶的大小设置和桶中含有的entry个数设置
#######dmesg结果显示：PID hash table entries: 4096 (order: 12, 16384 bytes)
#######pidhash_size(桶大小）：4096*4bytes entries:4096
#######也就是说桶中存有4096个指针，指针指向struct hlist_node结构
316 for (i = 0; i < PIDTYPE_MAX; i++) {
317 pid_hash[i] = alloc_bootmem(pidhash_size *
318 sizeof(*(pid_hash[i])));
#######在系统启动期间slab和alloc分配器都还没有建立好
#######采用allocbootmem内存分配器对系统初始化期间的内存进行分配
319 if (!pid_hash[i])
320 panic("Could not alloc pidhash!\n");
321 for (j = 0; j < pidhash_size; j++)
322 INIT_HLIST_HEAD(&pid_hash[i][j]);
#######将桶中指向struct hlist_node 结构的指针first初始化为NULL
323 }
经过这个函数 pid哈希链表 被初始化完成。
与此同时，start_kernel期间也对pid位图进行了相应的初始化。利用pid位图对进程pid号进行管理是一种简单并且高效的形式。（bit：0代表这个pid可以使用bit：1代表这个pid已经被占用）
系统在初始化期间手动的为表示进程pid号的位图分配空间并且初始化。
- 50 typedef struct pidmap {
- 51 atomic_t nr_free;
- 52 void *page;
- 53 } pidmap_t;
- 55 static pidmap_t pidmap_array[PIDMAP_ENTRIES] =
- 56 { [ 0 ... PIDMAP_ENTRIES-1 ] = { ATOMIC_INIT(BITS_PER_PAGE), NULL } };
位图初始化期间：利用get_zeroed_page函数为位图提供一个物理上的页框，并且此页框被实现初始化为0.
这样，一个大小为4K的物理页框，可以表示的进程号个数为：4*1024*8=32768；
但是有一点我们要主要：由于进程号0的特殊性，我们事先将其设置为不可用，也就是将位图的0号位设置为1，并把相应表示目前可用的pid号的个数减1.
- 326 void __init pidmap_init(void)
- /* */
- 327 {
- 328 int i;
- 329
- 330 pidmap_array->page = (void *)get_zeroed_page(GFP_KERNEL);
- 331 set_bit(0, pidmap_array->page);
- 332 atomic_dec(&pidmap_array->nr_free);
- 333
- 334 /*
- 335 * Allocate PID 0, and hash it via all PID types:
- 336 */
- 337
- 338 for (i = 0; i < PIDTYPE_MAX; i++)
- 339 attach_pid(current, i, 0);
- 340 }
上述代码通过attach_pid函数将0号进程进行hash，将其hash到上面已经初始化好的hash链表桶中。
我们知道每个进程中都有：struct pid pids[PIDTYPE_MAX]；而hash链表正是通过这个结构进行链接。
上述函数中，首先通过find_pid函数在指定类型和nr号的哈希链表中查找pid结构。如果找到则返回指向struct pid的指针 否则返回NULL。
接下来的代码根据find_pid的返回值，做出相应的动作。
1）pid为NULL，说明新attach的包含struct pid的进程描述符是哈希链表的第一个元素，将其插入头结点之后，并将struct pid的pid_list字段设置为NULL。struct list_head pid_list是由于连接具有相同nr号的进程描述符的连接件。
2）pid不为NULL,说明相应的哈希链表中已经存在了nr号为“nr”的进程描述符，我们只需将我们的进程描述符attach到相应的哈希链表的进程链表中。
通过上面的两个函数我们还可以得知：所有桶中（一般为4个）0号索引对应的哈希链表的第一个进程描述符元素都为0号进程的进程描述符。
而与attach_pid函数对应的操作为dettach_pid：将pid所在的进程描述符从对应的pid哈希链表中删除，这个函数的定义如下：
- 192 void fastcall detach_pid(task_t *task, enum pid_type type)
- /* */
- 193 {
- 194 int tmp, nr;
- 195
- 196 nr = __detach_pid(task, type);
- 197 if (!nr)
- 198 return;
- 199
- 200 for (tmp = PIDTYPE_MAX; --tmp >= 0; )
- 201 if (tmp != type && find_pid(tmp, nr))
- 202 return;
- 203
- 204 free_pidmap(nr);
- 205 }
核心函数为__detach_pid(task,type)
- 166 static fastcall int __detach_pid(task_t *task, enum pid_type type)
- /* */
- 167 {
- 168 struct pid *pid, *pid_next;
- 169 int nr = 0;
- 170
- 171 pid = &task->pids[type];
- 172 if (!hlist_unhashed(&pid->pid_chain)) {
- 173
- 174 if (list_empty(&pid->pid_list)) {
- 175 nr = pid->nr;
- 176 hlist_del_rcu(&pid->pid_chain);
- 177 } else {
- 178 pid_next = list_entry(pid->pid_list.next,
- 179 struct pid, pid_list);
- 180 /* insert next pid from pid_list to hash */
- 181 hlist_replace_rcu(&pid->pid_chain,
- 182 &pid_next->pid_chain);
- 183 }
- 184 }
- 185
- 186 list_del_rcu(&pid->pid_list);
- 187 pid->nr = 0;
- 188
- 189 return nr;
- 190 }
函数首先判断task指向的进程是否已经被hash进pid哈希链表，注意有可能是哈希链表中的进程链表。
如果不是哈希链表的节点，直接将其从所在的进程链表中删除。此时返回nr=0，我们后面可以看到，detach_pid函数根据nr值来判断是否需要将pid位图中相应的pid位清0，以此来使继续可以被使用。
如果是hash链表中的节点，还要判断
1）是否此哈希链表节点所在的进程链表只有这个节点。如果是将nr设置为pid->nr 并将这个节点删除
2）如果哈希链表节点所在的进程链表还有别的节点。那么用下一个节点replace这个节点。注意此时并未设置nr的值。也就是说返回的nr=0
当从__datach_pid返回后，接下来的任务就是判断是否需要将pid对应的pid位图中相应的位清0
1）如果nr=0，不需要清0 函数直接返回。通过上面我们知道，函数在两种情况下会返回nr=0 ：
一，进程链表非空（此时暗指的含义就是这个pid还被其余的进程/线程使用着，不能在位图中将其释放；
二，删除的就是nr=0的进程描述符。这是也不需要在位图中将其释放；因为0号pid比较特殊是不允许其他进程使用的。
2）如果nr不等于0，还要判断在其他类型的哈希链表中是否存在这样的进程描述符，如果存在也表明其正在使用不能释放。
如果上述两步都没有return那么的确是需要将pid位图中想的pid表示位清0，以供系统使用。
上述的代码中有一处理解容易出现问题：
- 200 for (tmp = PIDTYPE_MAX; --tmp >= 0; )
- 201 if (tmp != type && find_pid(tmp, nr))
- 202 return;
为什么只搜索其他类型的hash链表而不处理我们刚刚将其删pid的类型的hash链表呢？因为对于刚刚删除的进程描述符的类型的hash链表 我们应经用nr的值来表明是否需要清位图位了。
如果nr=0那么删除的进程描述符所在的进程链表是非空的---不必删除
如果进程链表是空的那么nr=pid-->nr我们不考虑0号pid那么这个nr一定为非0就说明我这个类型的hash链表不用这个进程号了 你查查其他类型的hash链表是否还使用吧。
如果其他有一个在使用，OK 不删返回。如果都不用，那么我就清理门户pidbitmap 相应位设置为0了。
文章出处：http://blog.chinaunix.net/uid-25538637-id-271546.html