Messages in this thread |  | | | Date | Tue, 17 Nov 1998 22:40:15 -0500 | | From | David Feuer <> | | Subject | Re: unexpected paging during large file reads in 2.1.127 |
| |
Rik van Riel wrote: > > On Mon, 16 Nov 1998, Stephen C. Tweedie wrote: > > On Mon, 16 Nov 1998 21:48:35 +0100 (CET), Rik van Riel > > <H.H.vanRiel@phys.uu.nl> said: > > > On Mon, 16 Nov 1998, Stephen C. Tweedie wrote: > > >> The real cure is to disable page aging in the page cache completely. > > >> Now that we have disabled it for swap, it makes absolutely no sense at > > >> all to keep it in the page cache. > > > > > This is not entirely true. There is a major difference > > > between pages in the page cache and pages that can go > > > into swap. The latter kind will always be mapped inside > > > the address space of a program (where it gets proper > > > aging and stuff) > > > > No it doesn't, that's what I'm saying. Linus removed swap page aging in > > the recent kernels. That throws the balance between swap and cache > > completely out of the window: removing the page cache aging is necessary > > to restore balance. There are many many reports of massive cache growth > > on the latest kernels as a result of this. > > I meant the page aging that occurs in vmscan.c, where we > decide on which page to unmap from a program's address > space. There we do aging while we don't age pages from > files that are read(). > > > > Now we can get severe problems with readahead when we > > > are evicting just read-in data because it isn't mapped, > > > > No, we don't. We don't evict just-read-in data, because we mark such > > pages as PG_Referenced. It takes two complete shrink_mmap() passes > > before we can evict such pages. > > OK, I can (and have for quite a while) agree with this. > Kernels with this feature and enough memory will run great, > maybe small machines (<16M) will have a bit of trouble > keeping up readahead performance (since kswapd will have > made it's round a bit fast) but those machines will have > sucky performance anyway :) > > Rik -- slowly getting used to dvorak kbd layout... <snip>
The Dvorak layout is obviously superior to that ancient Sholes thing most people store on their desks :)
It might not be elegant, but wouldn't it be possible to have different MM code depending on the amount of memory on the system? This could either be compiled-in (yuck) or else set at boot time...... Don't know how this would impact efficiency. --
______________________________ / David Feuer \ | dfeuer@binx.mbhs.edu | | feuer@his.com | \ david@feuer.his.com / ----------------------------- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
|  |