> And I *do* know that the real world simply isn't simple enough that we could
> ever do a perfect job, so don't even try - instead aim for "understandable,
> maintainable, and gets the main issues roughly right".
Toward better NUMA scheduling http://lwn.net/Articles/486858/
Peter's cited email: http://lwn.net/Articles/486850/
Actually, in reviewing the data, it seems this issue has been around for a long time, and could be the root of Linus's irritation in the first place. Perhaps he feels no headway is being made for such a long time, even the smallest perceived misstep sets him off.
If nothing else, I would love to actually see some technically detailed papers come out of this that get to the root of the problem, propose solutions to it, and identify what of those solutions are being tested and when they are expected to be implemented. Nothing like a good argument between engineers to get a root cause rooted out and a solution in place.
"the result of these commits is: 24 files changed, 417 insertions(+), 975 deletions(-)
Most of the linecount win is due to the removal of the dysfunctional power scheduling - but even without that commit it's a simplification:
15 files changed, 415 insertions(+), 481 deletions(-)
while it lifts the historic limitations of the sched-domains approach and makes the code a whole lot more logical."
Architectures/ABIs with 64bit pointers have a much lower probability of arbitrary values mapping to active memory space for the process, so memory bloat caused by the conservative GC strategy is much more limited.
The x32 abi looks like it would suffer from this 32bit conservative garbage collection problem too. Short of changing the VM strategy, using 64 bit pointers is the only way to ensure that such VMs do not accumulate so much unused but not-garbage-collectable memory allocations.
(i can dig out a post of (afair) solar designer that goes into more detail, but i think this should be clear as is)
Well, Donald Knuth for one. Here's a blog entry I wrote about Donald Knuth and how he asked for this a while back. I think it makes a lot of sense and I'm really glad to see this maturing!
http://blog.reverberate.org/2011/09/making-knuth-wish-come-t...
http://www-cs-faculty.stanford.edu/~uno/news08.html
Saving 32bits means a lot to him.
There are still many features where linux is just playing catch-up that commercial unix kernels had decades ago.
This problem is really a quirk that results from the fact that AMD made significant changes to the arch(added 16 registers) when they invented amd64.
Basically you can choose if you want your program to have only 4 GB address space and thus only consume 4 bytes of memory per pointer. This is a per-process choice. (but obviously requires special binaries)