The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Daniel Phillips <phillips@bonn-fries.net>
To: Boszormenyi Zoltan <zboszor@freemail.hu>, linux-kernel@vger.kernel.org
Subject: Re: used-once really works?
Date: Tue, 31 Jul 2001 18:39:11 +0200	[thread overview]
Message-ID: <01073118391103.00303@starship> (raw)
In-Reply-To: <freemail.20010631154204.52946@fm5.freemail.hu>
In-Reply-To: <freemail.20010631154204.52946@fm5.freemail.hu>

On Tuesday 31 July 2001 15:42, Boszormenyi Zoltan wrote:
> Hi!
>
> I freshly compiled 2.4.8-pre3 and I thought
> I give it a try.
>
> The machine is a dual P3 with 384MB memory and one
> 15 GB IDE disk, distro is RedHat 6.2 with official
> upgrades and e2fsprogs-1.22 and GNOME-1.4.
>
> In X, I had mozilla, and 3 gnome-terminals running.
> In one terminal, I run 'top', in one other
> 'dd if=/dev/hda of=/dev/null bs=4096'.
>
> 'top' showed that the system buffer cache filled up
> and soon the machine started swapping. It seemed to swap
> out mozilla and parts of the X server. Otherwise the
> system remained responsive.

There is no specific use-once handling for buffers so what happens is

  touch_buffer->SetPageReferenced

causes all referenced buffer pages to be moved lazilly from the 
inactive to active queue and unused readahead buffers to be dropped 
quickly.  It would be better if there were use-once handling for 
buffers too, so that your dd doesn't fill up memory and cause a (still 
mysterious to me) chain of events that ends up in swapping.

> I tried other more experimental patches, too:
> o_direct-10 and blkdev-pagecache-5. There was a one-liner
> reject in mm/vmscan.c after applying blkdev-pagecache-5.
>
> I fixed this and booted this new kernel, I tried the same.
> This time the page cache started to fill up but
> no swapping occured. Hm...
>
> During 'dd' starting new (I mean: not yet in the page cache)
> programs were slow as hell. Starting them second time was
> fast as expected.

The blkdev-pagecache patch is highly relevant to the discussion because 
it moves the dd resource load from buffers to the page cache, changing 
the behaviour of the system a great deal as you saw.  I think what is 
happening is, use-once makes a lot more inactive pages available from 
the dd so the system sees no need to go into swap (good).  But we also 
lose the scanning behaviour that used to throttle the dd process.  It 
now picks up new IO pages so quickly that it usually wins the 
competition for IO bandwidth.  (N.B., this is a *theory*, measurements 
needed.  If it's correct then we have to look at ways to be fairer 
about IO, something that's been needed for a long time anyway.)

> I tried glade with a large project file,
> loading it / looking into directories was slow at first,
> was fast second time. Since ext2 directories are in the
> page cache, this is perfectly understandable.

Yes, there is also no use-once handling for ext2 directories so the 
default behaviour is to lazily activate them.  Since directory pages 
are never treated as use-once, and they get a default boost in priority 
vs file IO.  It's probably ok to just leave it that way.

> So it seems that the used-once patch works.
> The only comments is that I didn't expect it
> to start swapping with the stock pre3.
> I supposed it frees the "used-once" pages more quickly.
> Anyway I am not a VM expert and don't flame me about
> my non relevant comments. 2.4.8 seems promising :-)

A little bit of digging should answer the swapping question.  Adding 
use-once handling to buffers should be a one-liner, after moving the 
check_used_once into a header.  I'll try it first before making any 
claims ;-)

--
Daniel

      reply	other threads:[~2001-07-31 16:34 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-07-31 13:42 used-once really works? Boszormenyi Zoltan
2001-07-31 16:39 ` Daniel Phillips [this message]

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=01073118391103.00303@starship \
    --to=phillips@bonn-fries.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=zboszor@freemail.hu \
    /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