From: Daniel Phillips <phillips@bonn-fries.net>
To: Rik van Riel <riel@conectiva.com.br>,
Marcelo Tosatti <marcelo@conectiva.com.br>
Cc: <linux-kernel@vger.kernel.org>, Ben LaHaise <bcrl@redhat.com>,
Mike Galbraith <mikeg@wen-online.de>
Subject: Re: [RFC] Optimization for use-once pages
Date: Wed, 25 Jul 2001 00:41:12 +0200 [thread overview]
Message-ID: <01072500411205.00520@starship> (raw)
In-Reply-To: <Pine.LNX.4.33L.0107241903410.20326-100000@duckman.distro.conectiva>
In-Reply-To: <Pine.LNX.4.33L.0107241903410.20326-100000@duckman.distro.conectiva>
On Wednesday 25 July 2001 00:05, Rik van Riel wrote:
> On Tue, 24 Jul 2001, Marcelo Tosatti wrote:
> > On Tue, 24 Jul 2001, Daniel Phillips wrote:
> > > Today's patch tackles the use-once problem, that is, the problem
> > > of
> >
> > Well, as I see the patch should remove the problem where
> > drop_behind() deactivates pages of a readahead window even if
> > some of those pages are not "used-once" pages, right ?
> >
> > I just want to make sure the performance improvements you're
> > seeing caused by the fix of this _particular_ problem.
>
> Fully agreed.
>
> Especially since it was a one-liner change from worse
> performance to better performance (IIRC) it would be
> nice to see exactly WHY the system behaves the way it
> does. ;)
Oh, it wasn't an accident, I knew what I was trying to achieve.
It's just that I didn't immediately understand all the curlicues in
the page life cycles just from staring at the code. I had to see
the machine moving first. It was very instructive to see what
happened on reverting to a fifo strategy. It might even be a good
idea to put a proc hook in there to allow on-the-fly dumbing down
of the lru machinery. That way we can measure system behaviour
against a baseline without having to go through the
compile-reboot-bench cycle every time, which eats a major amount
of time.
> Reading a bunch of 2Q, LRU/k, ... papers and thinking
> about the problem very carefully should help us a bit
> in this. Lots of researches have already looked into
> this particular problem in quite a lot of detail.
Yep, unfortunately the subject of memory management in operating
systems seems to have received a lot less attention than memory
management in databases.
--
Daniel
next prev parent reply other threads:[~2001-07-24 23:08 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-07-24 3:47 [RFC] Optimization for use-once pages Daniel Phillips
2001-07-24 12:38 ` jlnance
2001-07-24 16:56 ` Rik van Riel
2001-07-25 0:04 ` Daniel Phillips
2001-07-25 0:43 ` Anton Altaparmakov
2001-07-25 1:30 ` Daniel Phillips
2001-07-25 21:18 ` Steve Lord
2001-07-24 16:48 ` Linus Torvalds
2001-07-24 17:04 ` Rik van Riel
2001-07-24 18:14 ` Daniel Phillips
2001-07-24 18:15 ` Rik van Riel
2001-07-24 19:41 ` Is /dev/epoll scheduled for official inclusion anytime soon? David E. Weekly
2001-07-24 20:05 ` Rik van Riel
2001-07-24 20:26 ` linux partitioning in IA64 hiufungeric.tse
2001-07-25 9:29 ` Mike A. Harris
2001-07-24 20:24 ` [RFC] Optimization for use-once pages Patrick Dreker
2001-07-24 20:32 ` Rik van Riel
2001-07-24 22:16 ` Patrick Dreker
2001-07-24 22:25 ` Rik van Riel
2001-07-25 0:27 ` Linus Torvalds
2001-07-25 8:20 ` Patrick Dreker
2001-07-25 12:57 ` Martin Devera
2001-07-25 14:16 ` Daniel Phillips
2001-07-24 20:33 ` Linus Torvalds
2001-07-25 1:25 ` Daniel Phillips
2001-07-25 0:18 ` Daniel Phillips
2001-07-24 20:27 ` Marcelo Tosatti
2001-07-24 22:05 ` Rik van Riel
2001-07-24 20:53 ` Marcelo Tosatti
2001-07-24 22:27 ` Rik van Riel
2001-07-24 23:09 ` Daniel Phillips
2001-07-24 19:35 ` Rob Landley
2001-07-25 6:10 ` Marcelo Tosatti
2001-07-25 8:32 ` Eric W. Biederman
2001-07-25 12:53 ` Daniel Phillips
2001-07-25 16:05 ` Eric W. Biederman
2001-07-25 12:57 ` Daniel Phillips
2001-07-25 5:12 ` Andrew Morton
2001-07-25 6:33 ` Marcelo Tosatti
2001-07-30 18:09 ` Marcelo Tosatti
2001-07-24 22:41 ` Daniel Phillips [this message]
2001-07-24 22:22 ` Daniel Phillips
2001-07-25 2:31 ` Marcelo Tosatti
[not found] <010301c11463$1ee00440$294b82ce@connecttech.com>
2001-07-24 17:07 ` Rik van Riel
2001-07-24 17:42 ` Stuart MacDonald
2001-07-24 17:51 ` Rik van Riel
2001-07-24 18:09 ` Stuart MacDonald
2001-07-24 18:15 ` Mike Castle
2001-07-24 18:21 ` Rik van Riel
2001-07-24 17:44 ` Mike Castle
2001-07-24 17:52 ` Rik van Riel
[not found] <0107251802300B.00907@starship>
2001-07-25 16:41 ` Rik van Riel
2001-07-25 17:46 ` Daniel Phillips
2001-07-26 8:36 ` Eric W. Biederman
2001-07-26 12:06 ` Daniel Phillips
2001-07-26 10:38 ` Marcelo Tosatti
2001-07-26 12:17 ` Daniel Phillips
-- strict thread matches above, loose matches on Subject: below --
2001-07-26 3:27 Ed Tomlinson
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=01072500411205.00520@starship \
--to=phillips@bonn-fries.net \
--cc=bcrl@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo@conectiva.com.br \
--cc=mikeg@wen-online.de \
--cc=riel@conectiva.com.br \
/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.