Messages in this thread | | | Date | Mon, 27 Jun 2005 18:02:15 +1000 | From | Nick Piggin <> | Subject | Re: [rfc] lockless pagecache |
| |
Andrew Morton wrote: > Nick Piggin <nickpiggin@yahoo.com.au> wrote: > >>First I'll put up some numbers to get you interested - of a 64-way Altix >> with 64 processes each read-faulting in their own 512MB part of a 32GB >> file that is preloaded in pagecache (with the proper NUMA memory >> allocation). > > > I bet you can get a 5x to 10x reduction in ->tree_lock traffic by doing > 16-page faultahead. > >
Definitely, for the microbenchmark I was testing with.
However I think for Oracle and others that use shared memory like this, they are probably not doing linear access, so that would be a net loss. I'm not completely sure (I don't have access to real loads at the moment), but I would have thought those guys would have looked into fault ahead if it were a possibility.
Also, the memory usage regression cases that fault ahead brings makes it a bit contentious.
I like that the lockless patch completely removes the problem at its source and even makes the serial path lighter. The other things is, the speculative get_page may be useful for more code than just pagecache lookups. But it is fairly tricky I'll give you that.
Anyway it is obviously not something that can go in tomorrow. At the very least the PageReserved patches need to go in first, and even they will need a lot of testing out of tree.
Perhaps it can be discussed at KS and we can think about what to do with it after that - that kind of time frame. No rush.
Oh yeah, and obviously it would be nice if it provided real improvements on real workloads too ;)
-- SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
- 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/
| |