mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Buddy Lumpkin" <b.lumpkin@attbi.com>
To: "Alan Cox" <alan@lxorguk.ukuu.org.uk>
Cc: "Austin Gonyou" <austin@digitalroadkill.net>,
	<vda@port.imtp.ilyichevsk.odessa.ua>,
	"Ville Herva" <vherva@niksula.hut.fi>,
	"DervishD" <raul@pleyades.net>,
	"Linux-kernel" <linux-kernel@vger.kernel.org>
Subject: RE: About the need of a swap area
Date: Sat, 27 Jul 2002 16:34:34 -0700	[thread overview]
Message-ID: <FJEIKLCALBJLPMEOOMECMEPKCPAA.b.lumpkin@attbi.com> (raw)
In-Reply-To: <1027816089.21516.9.camel@irongate.swansea.linux.org.uk>



On Sun, 2002-07-28 at 00:01, Buddy Lumpkin wrote:
>> Are you implying that it should be looking for pages to swap out this
whole
>> time to free up more space for filesystem and executable pages purely
based
>> on lru? Have you done testing to prove that this is a better approach
than
>> setting a threshold of when to wake up the lru mechanism?

>Not all the time - when there is pressure to find more pages.

ok, then it turns out that we agree, Solaris does "the right thing" in this
respect.


>> Solaris keeps dirty pages after they have been flushed to their backing
>> store, it's just when the system has to choose something to flush that it
>> preferences filesystem over anonymous and executable, what's wrong with
>> that?

>Many of its pages are both file system and executable. Solaris shares
>read-only pages between the caches and the mappings into process spaces.
>I can understand favouring flushing mapped files because swap is
>generally slower than restoring a file backed mapping

right, solaris share everything!

it maps text, data, etc... MAP_PRIVATE (COW) and uses the segmap to unify
access between read, write and mmaped MAP_SHARED pages so that
only a single page exists for any single filesystem page. You can see proof
of this by writing a little C program and then while it's running modify it
(say it prints for instance changes from "this is a test" to "this xx a
xxxx" ) and overwrite the new file with mmap MAP_SHARED type access or with
write(), the programs output will change on the fly while it's running.

When I differentiate between filesystem pages and executable, I should have
been specific in saying that executable pages almost always have a named
file as thier backing store, but for this discussion executable means that
the page has the execute bit set.

For priority paging they actually warn that standard files that are mmapped
will be incorrectly treated like executables if they have the execute bits
set. This probably happens quite often so it's not perfect.

--Buddy





  reply	other threads:[~2002-07-27 23:30 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-27 12:22 DervishD
2002-07-27 14:42 ` Ville Herva
2002-07-27 15:47   ` Rik van Riel
2002-07-27 20:41     ` Buddy Lumpkin
2002-07-27 20:50       ` Rik van Riel
2002-07-27 16:11   ` DervishD
2002-07-27 17:01     ` Ville Herva
2002-07-28 11:04       ` DervishD
2002-07-29 13:14       ` [lkml] " Ian Soboroff
2002-07-28  0:02   ` Denis Vlasenko
2002-07-27 20:58     ` Austin Gonyou
2002-07-27 22:22       ` Buddy Lumpkin
2002-07-27 23:40         ` Alan Cox
2002-07-27 22:35           ` Rik van Riel
2002-07-27 22:49             ` Buddy Lumpkin
2002-07-27 23:36               ` Daniel Phillips
2002-07-27 22:39           ` Buddy Lumpkin
2002-07-28  0:03             ` Alan Cox
2002-07-27 22:52               ` Rik van Riel
2002-07-27 23:01               ` Buddy Lumpkin
2002-07-28  0:28                 ` Alan Cox
2002-07-27 23:34                   ` Buddy Lumpkin [this message]
2002-07-28  6:58             ` Ville Herva
2002-07-28  7:59               ` Buddy Lumpkin
2002-07-28  8:19                 ` Ville Herva
2002-07-28 14:11               ` Rik van Riel
2002-07-28 15:57                 ` Ville Herva
2002-07-28 18:48               ` Buddy Lumpkin
2002-07-28 18:58                 ` Ed Sweetman
2002-07-28 19:29                   ` Rik van Riel
2002-07-28 19:47                     ` Ed Sweetman
2002-07-28 20:42                       ` Buddy Lumpkin
2002-07-28 20:27                 ` Ville Herva
2002-07-30 19:31           ` Andy Isaacson
2002-07-28 16:20         ` Austin Gonyou
2002-07-29  7:18 ` Val Henson

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=FJEIKLCALBJLPMEOOMECMEPKCPAA.b.lumpkin@attbi.com \
    --to=b.lumpkin@attbi.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=austin@digitalroadkill.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=raul@pleyades.net \
    --cc=vda@port.imtp.ilyichevsk.odessa.ua \
    --cc=vherva@niksula.hut.fi \
    /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

all inboxes | Powered by JetHome®