Re: [PATCH 00/18] Make common x86 arch area for i386 and x86_64 -Take 2
From: Martin Bligh
Date: Fri Mar 16 2007 - 16:26:34 EST
Christoph Lameter wrote:
On Fri, 16 Mar 2007, Andi Kleen wrote:
x86_64 is going to acquire more functionality that will not be available
for i386. We plan f.e. to add virtual memmap support for x86_64. Virtual
What advantage would that have over the current setup?
We already should handle holes between nodes reasonably efficiently
and with nonlinear memory even holes inside nodes shouldn't be a problem.
It is primarily a performance improvement since the sparsemem table
lookups would no longer be necessary and it also streamlines other
frequent cacheline uses. These page -> page_struct and vice versa
operations are key to the performance of various subsystem among them
the slab allocator.
cc: apw
You have to do some sort of lookup anyway, and Andy seemed to have them
all folded into one.
Or are you trying to avoid this by going to back to the crud we had
in 2.4 where we pretend mem_map is one big array, indexed by pfn with
huge sparsely mapped holes in it?
Would be nice to work out (and document somewhere) what the pros and
cons of virtual memmap vs sparsemem were - ISTR one of the arguments
was extremely sparsely layed out machines, and you needed sparsemem
for that. But right now we have 3 solutions, which is not a good
situation.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/