user/sven/linux.git/kernel/pid.c, branch v2.6.16.6

[PATCH] RCU signal handling

2006-01-09T04:13:40Z

RCU tasklist_lock and RCU signal handling: send signals RCU-read-locked instead of tasklist_lock read-locked. This is a scalability improvement on SMP and a preemption-latency improvement under PREEMPT_RCU. Signed-off-by: Paul E. McKenney Signed-off-by: Ingo Molnar Acked-by: William Irwin Cc: Roland McGrath Cc: Oleg Nesterov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] Lock initializer cleanup (Core)

2005-01-08T06:09:06Z

Kernel core files converted to use the new lock initializers. Signed-off-by: Thomas Gleixner Acked-by: Ingo Molnar Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] detach_pid(): eliminate one find_pid() call

2004-10-20T01:31:59Z

Now there is no point in calling costly find_pid(type) if __detach_pid(type) returned non zero value. Acked-By: Kirill Korotaev Signed-off-by: Oleg Nesterov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] detach_pid(): restore optimization

2004-10-20T01:31:47Z

Kirill's kernel/pid.c rework broke optimization logic in detach_pid(). Non zero return from __detach_pid() was used to indicate, that this pid can probably be freed. Current version always (modulo idle threads) return non zero value, thus resulting in unneccesary pid_hash scanning. Also, uninlining __detach_pid() reduces pid.o text size from 2492 to 1600 bytes. Acked-By: Kirill Korotaev Signed-off-by: Oleg Nesterov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] pidhashing: enforce PID_MAX_LIMIT in sysctls

2004-10-19T01:10:55Z

The pid_max sysctl doesn't enforce PID_MAX_LIMIT or sane lower bounds. RESERVED_PIDS + 1 is the minimum pid_max that won't break alloc_pidmap(), and PID_MAX_LIMIT may not be aligned to 8*PAGE_SIZE boundaries for unusual values of PAGE_SIZE, so this also rounds up PID_MAX_LIMIT to it. Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] pidhashing: retain older vendor copyright

2004-10-19T01:10:31Z

I was informed that the vendor component of the copyright can't be clobbered without more care, so this patch retains the older vendor, updating it only to reflect the appropriate time period. Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] pidhashing: rewrite alloc_pidmap()

2004-10-19T01:10:19Z

Rewrite alloc_pidmap() to clarify control flow by eliminating all usage of goto, honor pid_max and first available pid after last_pid semantics, make only a single pass over the used portion of the pid bitmap, and update copyrights to reflect ongoing maintenance by Ingo and myself. Signed-off-by: William Irwin Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] Allocate correct amount of memory for pid hash

2004-09-14T00:46:50Z

We are now allocating twice as much memory as required. Signed-off-by: Anton Blanchard Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] fixed pidhashing patch

2004-09-02T07:42:48Z

This patch fixes strange and obscure pid implementation in current kernels: - it removes calling of put_task_struct() from detach_pid() under tasklist_lock. This allows to use blocking calls in security_task_free() hooks (in __put_task_struct()). - it saves some space = 5*5 ints = 100 bytes in task_struct - it's smaller and tidy, more straigthforward and doesn't use any knowledge about pids using and assignment. - it removes pid_links and pid_struct doesn't hold reference counters on task_struct. instead, new pid_structs and linked altogether and only one of them is inserted in hash_list. Signed-off-by: Kirill Korotaev (kksx@mail.ru) Signed-off-by: William Irwin Signed-off-by: Linus Torvalds

[PATCH] use hlist for pid hash

2004-08-31T03:36:01Z

Use hlists for the PID hashes. This halves the memory footprint of these hashes. No benchmarks, but I think this is a worthy improvement because the hashes are something that would be likely to have significant portions loaded into the cache of every CPU on some workloads. This comes at the "expense" of 1. reintroducing the memory prefetch into the hash traversal loop; 2. adding new pids to the head of the list instead of the tail. I suspect that if this was a big problem then the hash isn't sized well or could benefit from moving hot entries to the head. Also, account for all the pid hashes when reporting hash memory usage. Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds