Messages in this thread | | | Date | Mon, 14 Apr 2003 19:14:19 +0200 | From | Antonio Vargas <> | Subject | Re: Quick question about hyper-threading (also some NUMA stuff) |
| |
On Mon, Apr 14, 2003 at 09:37:07AM -0700, Martin J. Bligh wrote: > >> OK, unless I misunderstand you, I think that happens naturally for that > >> kind of thing - when we do the COW split, we'll get a node-local page > >> by default (unless the local node is out of memory). > > > > Yes, it happens naturaly, but it's done when we try to write to it. > > What I meant was, at fork time, it we are forking to a different node, > > instead of COW-marking, do the COW-mark and the immediately do a sort-of > > for_each_page(touch_as_if_written(page)), so that nodes would not have to > > reference the memory from others. > > 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.
btw, COW-ahead sound really silly :)
> > I don't know if it's really usefull, and anyways I could not try to code it > > unless there is a sort of NUMA simulator for "normal" machines. > > There isn't, but writing one would be very useful (and fairly simple) if > you have a 2x machine or something that you could use. I've thought about > writing this several times ... just haven't got round to it. > > M.
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 :) - 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/
| |