Re: [PATCH 2/2] use hlist for pid hash

[Nick Piggin <nickpiggin@yahoo.com.au>]

[-- Attachment #1: Type: text/plain, Size: 986 bytes --]

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?

[-- Attachment #2: pid-search-cacheline.patch --]
[-- Type: text/x-patch, Size: 647 bytes --]




---

 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

_