Hi Nick,
> Use hlists for the PID hashes. This halves the memory footprint of these
> hashes. No benchmarks, but I think this is a worthy improvement because
> the hashes are something that would be likely to have significant portions
> loaded into the cache of every CPU on some workloads.
>
> This comes at the "expense" of
> 1. reintroducing the memory prefetch into the hash traversal loop;
> 2. adding new pids to the head of the list instead of the tail. I
> suspect that if this was a big problem then the hash isn't sized
> well or could benefit from moving hot entries to the head.
>
> Also, account for all the pid hashes when reporting hash memory usage.
It looks like we are now allocating twice as much memory as required.
How does this look?
Signed-off-by: Anton Blanchard <[email protected]>
diff -puN kernel/pid.c~fix_freemem_reporting kernel/pid.c
--- foobar2/kernel/pid.c~fix_freemem_reporting 2004-09-06 21:17:34.185012321 +1000
+++ foobar2-anton/kernel/pid.c 2004-09-06 21:25:29.494818586 +1000
@@ -278,7 +278,7 @@ void __init pidhash_init(void)
for (i = 0; i < PIDTYPE_MAX; i++) {
pid_hash[i] = alloc_bootmem(pidhash_size *
- sizeof(struct list_head));
+ sizeof(struct hlist_head));
if (!pid_hash[i])
panic("Could not alloc pidhash!\n");
for (j = 0; j < pidhash_size; j++)
_
Anton Blanchard wrote:
>>Also, account for all the pid hashes when reporting hash memory usage.
>
>
> It looks like we are now allocating twice as much memory as required.
> How does this look?
>
Fine. Good catch thanks Anton.