On Wed, 20 Sep 2000, Andrea Arcangeli wrote:
> On Wed, Sep 20, 2000 at 12:53:18PM -0300, Rik van Riel wrote:
> > On Tue, 19 Sep 2000, Andrea Arcangeli wrote:
> > > On Tue, Sep 19, 2000 at 05:29:29AM -0300, Rik van Riel wrote:
> > > > what I wanted to do in the new VM, except that I didn't
> > > > see why we would want to restrict it to swap pages only?
> > >
> > > You _must_ do that _only_ for the swap_cache, that's a specific
> > > issue of the swap_cache during swapout (notenote: not during
> > > swapin!).
> >
> > Which part of "why" did you not understand?
> >
> > I see no reason why we should not do the same trick for
> > mmap()ed pages and maybe other memory too...
>
> It's quite obvious we not talking about the same thing (and it's also quite
> obvious the problem isn't addressed in test9), I'll restart from scratch trying
> to be more clear.
>
> There are two cases:
>
> 1) pageins
> 2) pageouts
>
> When we get a major page fault (pagein/swapin) and we create a
> swap cache page or a page-cache page, we must consider it a
> _more_ important page to keep in the working set. So it's fine
> to put it at the head->next of the LRU and to age it properly.
>
> So far so good.
>
> Now there's a very special (subtle) case that I addressed in
> classzone and that is only related to the swapout of a swap
> cache (well, strictly speaking the pageout of shared pages could
> take advantage of it as well but I didn't wrote a mechamism
> generic enough to do that for MAP_SHARED as well yet and that's
> much less important because the dirty page cache is just in the
> LRU and it have less chances to be in the lru_cache->next
> position).
Well, my VM patch /does/ have this mechanism more
generic and uses it for:
- swapout
- unmapped mmap() pages
- drop-behind for readahead
- drop-behind for generic_file_write
Since it seems clear that you want the same thing
but just didn't read my email, I guess we should
end this thread ;)
regards,
Rik
--
"What you're running that piece of shit Gnome?!?!"
-- Miguel de Icaza, UKUUG 2000
http://www.conectiva.com/ http://www.surriel.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
