Messages in this thread | | | From | Daniel Phillips <> | Subject | Re: 2.4.19pre1aa1 | Date | Mon, 4 Mar 2002 04:22:20 +0100 |
| |
On March 4, 2002 03:25 am, Andrea Arcangeli wrote: > On Mon, Mar 04, 2002 at 02:46:22AM +0100, Daniel Phillips wrote: > > As soon as you have shared pages you start to benefit from rmap's ability > > to unmap in one step, so the cost of creating the link is recovered by not > > we'd benefit also with unshared pages. > > BTW, for the map shared mappings we just collect the rmap information, > we need it for vmtruncate, but it's not layed out for efficient > browsing, it's only meant to make vmtruncate work.
Sorry, transmission error, what did you mean?
> > having to scan two page tables to unmap it. In theory. Do you see a hole > > in that? > > Just the fact you never need the reverse lookup during lots of > important production usages (first that cames to mind is when you have > enough ram to do your job, all number crunching/fileserving, and most > servers are setup that way). This is the whole point. Note that this > has nothing to do with the "cache" part, this is only about the > pageout/swapout stage, only a few servers really needs heavy swapout.
You always have to unmap the page at some point, so you win back the cost of creating the pte_chain there, hopefully. You could argue that paying the cost up front makes latency a little worse. You might have trouble measuring that though.
> ...Another bit in the current design of round robin cycling > over the whole VM clearing the accessed bitflag and activating physical > pages if needed, can also be see also as a feature in some ways. It is > much better at providing a kind of "clock based" aging to the accessed > bit information, while the lru pass rmap aware, wouldn't really be fair > with all the virtual pages the same way as we do now.
You get a perfectly good clock by scanning the lru list. It's not totally fair because a page newly promoted from the cold end to the hot end of the list will get scanned again after a much shorter delta-t, but it's hard to see why that's bad.
-- Daniel - 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/
| |