Messages in this thread Patch in this message | | | Date | Sun, 22 Aug 2004 15:31:44 +1000 | From | Nick Piggin <> | Subject | Re: [PATCH 2/2] use hlist for pid hash |
| |
David S. Miller wrote: > On Sun, 22 Aug 2004 14:46:38 +1000 > Nick Piggin <nickpiggin@yahoo.com.au> wrote: > > >>Any reason why this shouldn't be done? Anyone know of a decent test that >>stresses the pid hash? > > > I can't think of any way in which this could decrease > performance. I highly recommend this patch :-) >
Oh good :)
The only thing that could hurt is that the hash list traversal in find_pid now does prefetch.
This would be trivial to remove by introducing another list.h entity similar to __list_for_each for hlists, however I would have thought that if anything, the prefetch might help a tiny bit on the odd workloads where the number of tasks is much greater than the number of hash entries. Ingo? WLI?
I expect you could get a good bit of overlap on the prefetch if the next hash pointer isn't in the same cacheline as ->nr... although, on a 64-bit architecture with a 32byte cacheline size, this is guaranteed to be the case. Why not put them together?
---
linux-2.6-npiggin/include/linux/pid.h | 3 ++- 1 files changed, 2 insertions(+), 1 deletion(-)
diff -puN include/linux/pid.h~pid-search-cacheline include/linux/pid.h --- linux-2.6/include/linux/pid.h~pid-search-cacheline 2004-08-22 15:14:33.000000000 +1000 +++ linux-2.6-npiggin/include/linux/pid.h 2004-08-22 15:16:33.000000000 +1000 @@ -12,11 +12,12 @@ enum pid_type struct pid { + /* Try to keep hash_chain in the same cacheline as nr for find_pid */ + struct hlist_node hash_chain; int nr; atomic_t count; struct task_struct *task; struct list_head task_list; - struct hlist_node hash_chain; }; struct pid_link _
| |