Re: [RFC] ps command race fix

[KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>]

On Wed, 16 Aug 2006 22:59:50 -0600
ebiederm@xmission.com (Eric W. Biederman) wrote:

> 
> So I just threw something together that seems to work.
> 
> All of the pid are listed in order and the next used pid is found by
> scanning the pid bitmap. 
> 
> Scanning the pid bitmap might be a little heavy but actually is likely
> quite cache friendly as the accesses are extremely predictable, and
> everything should fit into 64 cache lines, which is fewer cache lines
> than walking a tree, and more predictable.  Of course I turn around
> and then do a hash table lookup which is at least one more cache line
> and probably an unpredictable one at that. 
> 
> The point despite the brute force nature I have no reason to suspect
> this will run any noticeably slower than the current implementation.
> 
> Look at this try it out and if this solves the problem we can push
> this upstream.
> 
At first, Thanks.

question:

	task = get_pid_task(find_next_pid(tgid), PIDTYPE_PID);

Does this return only "task/process" ? and never return "thread" ?

My another concern is that newly-created-process while ps running cannot be catched
by this kind of "table walking" approach (as my previous work)
But if people say O.K, I have no complaint.

I(we)'ll post another list-based one in the next week, anyway.
(I can't go-ahead this week...)

-Kame

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/