>> Ah, you probably don't want to do that ... it's very expensive. Moreover,
>> if you exec 2ns later, all the effort will be wasted ... and it's very
>> hard to deterministically predict whether you'll exec or not (stupid
>> UNIX semantics). Doing it lazily is probably best, and as to "nodes
>> would not have to reference the memory from others" - you're still
>> doing that, you're just batching it on the front end.
>
> True... What about a vma-level COW-ahead just like we have a file-level
> read-ahead, then? I mean batching the COW at unCOW-because-of-write time.
That'd be interesting ... and you can test that on a UP box, is not just
NUMA. Depends on the workload quite heavily, I suspect.
> btw, COW-ahead sound really silly :)
Yeah. So be sure to call it that if it works out ... we need more things
like that ;-) Moooooo.
> Not possible for me since I've got no SMP. But posting a quick note about
> your proposed "fake-NUMA-on-SMP.patch" would be good only if to have an
> offsite (offbrain also? ;) backup of your ideas :)
Oh, well basically you just need to split memory in half, and assign one
cpu to each "node" for each cpu_to_node thingy. Would be easy to just do it
as static #defines for sizes at first (most of the work in supporting a new
NUMA arch is just parsing the machinet tables). Set MAX_NUMNODES to > 1,
make sure you create a pgdat for each "node", and frig with build_zonelists
and free_area_init_core a bit.
M.
-
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/
This archive was generated by hypermail 2b29 : Tue Apr 15 2003 - 22:00:30 EST