From: "J.A. Magallon" <jamagallon@able.es>
To: Mark Mielke <mark@mark.mielke.cc>
Cc: Robert Love <rml@tech9.net>,
Lista Linux-Kernel <linux-kernel@vger.kernel.org>
Subject: Re: More on O_STREAMING (goodby read pauses)
Date: Fri, 11 Oct 2002 00:50:52 +0200 [thread overview]
Message-ID: <20021010225052.GE1676@werewolf.able.es> (raw)
In-Reply-To: <20021010180108.GB16962@mark.mielke.cc>; from mark@mark.mielke.cc on Thu, Oct 10, 2002 at 20:01:08 +0200
On 2002.10.10 Mark Mielke wrote:
>On Thu, Oct 10, 2002 at 04:39:27PM +0200, J.A. Magallon wrote:
>> On 2002.10.10 Mark Mielke wrote:
>> >I assume the stall is not 'while pages are sent to disk', but rather
>> >until kswapd gets around to freeing enough pages to allow memory to
>> >fill again. The stall is due to the pages being fully analyzed to
>> >determine which ones should go, and which ones shouldn't. O_STREAMING
>> >removes the pages ahead of time, so no analysis is ever required.
>> I can _hear_ the disk activity when the stall happens, so selecting what
>> to drop is fast, but then you have to write it...
>
>I don't think this is right. Prove me wrong by explaining how kswapd works,
>but if a page isn't dirty, there is no need to write it out to disk.
>
You suppose it is a page of code ? What about data that programs malloc() ???
You can also send data memory to swap. If you do not write it on disk,
how do you recover it ???
>My (perhaps incorrect) assumption is that kswapd prefers to swap on clean
>pages over dirty pages. If your pages are mostly clean, there is nothing
>to write to disk the clear majority of the time.
>
>Clean read-only pages should *never* be written to swap. They can be re-read
>from their source.
That is your fault, <read-only>. Pages maped read-only are those from
binary executables or shared libraries, but, again, what about data ?
>
>I _think_ what you are seeing is that kswapd is not cleaning pages out
>fast enough, which means that *other* tasks executing need to have their
>*swapped out* pages *read* from disk. I.e. the churning you hear is probably
>mostly reads - not writes.
>
I look at gnome system monitor graph for mem. I start with a tiny amount of
used memory. Start the 1Gb read without O_STREAM, the blue area in monitor
starts to grow linearly in time, stars (*) from the reader appear at a
given rate, and as soon as it touches the top limit the stars stop, the disk
begins to thrash, and swap space used grows. After a 2-4 seconds, the stars
go again with the same rate. Tell me what is this but swapper writing pages,
and reading the new pages for my giga.
With O_STREAM, the 'blue bar' does not move from its place, and star rate
(ie, read rate from disk), stays uniform.
--
J.A. Magallon <jamagallon@able.es> \ Software is like sex:
werewolf.able.es \ It's better when it's free
Mandrake Linux release 9.1 (Cooker) for i586
Linux 2.4.20-pre10-jam1 (gcc 3.2 (Mandrake Linux 9.0 3.2-2mdk))
next prev parent reply other threads:[~2002-10-10 22:45 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-09 22:23 More on O_STREAMING (goodby read pauses) J.A. Magallon
2002-10-09 22:43 ` Robert Love
2002-10-10 3:40 ` Mark Mielke
2002-10-10 14:39 ` J.A. Magallon
2002-10-10 18:01 ` Mark Mielke
2002-10-10 22:50 ` J.A. Magallon [this message]
2002-10-10 23:06 ` Andrew Morton
2002-10-11 2:04 ` Mark Mielke
-- strict thread matches above, loose matches on Subject: below --
2002-10-11 8:13 Samium Gromoff
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=20021010225052.GE1676@werewolf.able.es \
--to=jamagallon@able.es \
--cc=linux-kernel@vger.kernel.org \
--cc=mark@mark.mielke.cc \
--cc=rml@tech9.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.