From: "Stephen C. Tweedie" <sct@dcs.ed.ac.uk>
To: Rik van Riel <H.H.vanRiel@fys.ruu.nl>
Cc: "Stephen C. Tweedie" <sct@dcs.ed.ac.uk>,
"Benjamin C.R. LaHaise" <blah@kvack.org>,
Linus Torvalds <torvalds@transmeta.com>,
Itai Nahshon <nahshon@actcom.co.il>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
paubert@iram.es, Ingo Molnar <mingo@chiara.csoma.elte.hu>,
linux-mm@kvack.org
Subject: Re: PATCH: Swap shared pages (was: How to read-protect a vm_area?)
Date: Tue, 24 Feb 1998 23:38:14 GMT [thread overview]
Message-ID: <199802242338.XAA03262@dax.dcs.ed.ac.uk> (raw)
In-Reply-To: <Pine.LNX.3.91.980224102818.1909A-100000@mirkwood.dummy.home>
Hi,
On Tue, 24 Feb 1998 10:42:48 +0100 (MET), Rik van Riel
<H.H.vanRiel@fys.ruu.nl> said:
> [linux-kernel trimmed from f-ups]
> On Mon, 23 Feb 1998, Stephen C. Tweedie wrote:
>> The patch below, against 2.1.88, adds a bunch of new functionality to
>> the swapper. The main changes are:
>>
>> * All swapping goes through the swap cache (aka. page cache) now.
> Does this mean that _after_ the pages are properly aged
> as user-pages, they'll be aged again as page-cache pages?
> (when proper aging is added to the page cache, by eg. my patch)
No --- the swap cache is using the same data structures as the page
cache, but mainly to get lookup of swap entries still in physical
memory. The swapout code does not leave swapped pages around in memory
unnecessarily (although it does leave the door open to performing
readahead of swap, which _would_ look very much like the current page
cache readahead and would be reclaimed by shrink_mmap()).
The page cache swapout creates a page cache association for a page when
swapping begins, and clears the link when the swapping is finished. The
swap cache does not linger.
> I think it might be far better to:
> - put user-pages in the swap cache after they haven't been used
> for two aging rounds
> - free swap-cache pages and page-cache pages after they haven't
> been used for eight aging rounds (so the real aging and waiting
> takes place here)
> - use right-shift aging here {age << 1; if(touched) age |= 0x80}
> - adapt the get_free_pages so it can allocate clean page-cache and
> swap-cache pages when:
> - a bigorder area can't be found
> - there are no free pages left (and kswapd hasn't found new ones)
That is already scheduled as part of phase 4 of this work. The patch I
have just posted is phase 2, modifying the swapper for shared pages.
Phase three is to implement MAP_SHARED | MAP_ANONYMOUS, and part four is
to do much what you describe, proactively soft-swapping data out
into the swap cache up to a predefined limit, and allowing get_free_page
to reclaim these pages atomically even from within an interrupt. I have
already begun the work of spin-irq-locking the relevant page cache
structures.
> For more improvements, we could use Ben's pte_list <name?>
> patch so we could force-free bigorder areas and run somewhat
> more efficiently.
Ben has already been talking about some similar ideas, and I think that
yes, we do want to upgrade the swapout policy layer to work on a
physical page basis, using the pte_list walking to do its work. The
swap cache mechanism will still be needed to perform readahead and
writeahead, but the only reason I have had to integrate it so tightly
into the policy code right now is that without pte-walking there is no
other way to properly keep pages shared over swapping.
Ideally, we really want to have just one function walking over physical
pages for reclamation, and that function should be able to deal with
swap/filemap pages, page/swap cache, buffer cache and SysV shm pages as
they come up. I think that is achievable without too much more work
now, and it ought to give us much better performance from the swapper.
Cheers,
Stephen.
next prev parent reply other threads:[~1998-02-24 23:38 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <199802192321.XAA06580@dax.dcs.ed.ac.uk>
1998-02-20 5:41 ` How to read-protect a vm_area? Benjamin C.R. LaHaise
1998-02-23 23:17 ` PATCH: Swap shared pages (was: How to read-protect a vm_area?) Stephen C. Tweedie
1998-02-23 23:27 ` Linus Torvalds
1998-02-24 0:08 ` Benjamin C.R. LaHaise
1998-02-24 9:45 ` Stephen C. Tweedie
1998-02-24 9:42 ` Rik van Riel
1998-02-24 23:38 ` Stephen C. Tweedie [this message]
1998-02-25 10:41 ` Rik van Riel
1998-02-25 19:00 ` Stephen C. Tweedie
1998-02-25 22:05 ` Rik van Riel
1998-02-24 11:16 ` Thomas Sailer
[not found] ` <Pine.LNX.3.96.980224152231.7112A-100000@renass3.u-strasbg.fr>
1998-02-24 23:38 ` Stephen C. Tweedie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=199802242338.XAA03262@dax.dcs.ed.ac.uk \
--to=sct@dcs.ed.ac.uk \
--cc=H.H.vanRiel@fys.ruu.nl \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=blah@kvack.org \
--cc=linux-mm@kvack.org \
--cc=mingo@chiara.csoma.elte.hu \
--cc=nahshon@actcom.co.il \
--cc=paubert@iram.es \
--cc=torvalds@transmeta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox