[lkml]   [2004]   [Aug]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Patch in this message
SubjectRe: [PATCH 2/2] use hlist for pid hash
David S. Miller wrote:
> On Sun, 22 Aug 2004 14:46:38 +1000
> Nick Piggin <> 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
 \ /
  Last update: 2005-03-22 14:05    [W:0.060 / U:12.264 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site