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?