Messages in this thread | | | Date | Sun, 16 Mar 2003 13:35:16 -0800 | From | William Lee Irwin III <> | Subject | Re: [RFC] O(1) proc_pid_readdir |
| |
Ingo Molnar wrote: >> have you seen my "procfs/procps threading performance speedup" patch? It >> does something like this.
On Sun, Mar 16, 2003 at 10:24:34PM +0100, Manfred Spraul wrote: > Interesting patch. Do seekdir and telldir still work? I think you must > detect lseek calls and invalidate the cookie - either by hooking lseek > or by looking at f_version. > I think my solution for proc_pid_readdir() is better: You must fall back > to the old algorithm if the pid number stored in f_private got invalid > between two syscalls. I've modified the hash table slightly and search > for the next pid value directly, which works even if the current > position disappeared.
I'm heavily on the side of deterministic bounds here (these things trip the NMI oopser, so if the bounds aren't deterministic, neither is stability), so I favor manfred's proc_pid_readdir() algorithm.
It actually looks compatible with your prior patch aside from replacing and/or modifying its get_pid_list() speedup.
-- wli - 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/
| |