The current->pid tests date back to the 2.2 kernel patch, to get around
a bug where reusing an old task_struct didn't reinitialize the counter.
I'd much rather initialize the counter properly when a process starts, but
am not smart enough to track down all the places in the kernel where it
happens (kernel/fork.c only seems to account for half the pids on my system,
whereas in 2.4 virtually every process went through fork.c)
I originally had a much better RNG in place of the present one, but
at least one person didn't like explicit long-long calculations. Rather
than locking, what about the (admittedly much slower) nondeterministic RNG
interface? Also, the new __rmqueue is probably sufficiently slower than
the original (especially when accounting for non-power-of-two cache sizes)
that the latency for random numbers may not matter much.
Not sure how to handle pfn's properly in light of your observation, though.
What do you suggest? Likewise, I'll have to look at this per-cpu thing, older
patches didn't need to care about it.
Thanks to everyone for their feedback; I'll keep at it.
jasonp
---------------------------------------------
This message was sent using Endymion MailMan.
http://www.endymion.com/products/mailman/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/