linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Phillips <phillips@bonn-fries.net>
To: Mike Galbraith <mikeg@wen-online.de>,
	"Benjamin C.R. LaHaise" <blah@kvack.org>
Cc: Marcelo Tosatti <marcelo@conectiva.com.br>,
	Zlatko Calusic <zlatko.calusic@iskon.hr>,
	lkml <linux-kernel@vger.kernel.org>, <linux-mm@kvack.org>
Subject: Re: Comment on patch to remove nr_async_pages limitA
Date: Wed, 6 Jun 2001 00:21:33 +0200	[thread overview]
Message-ID: <01060600213307.00553@starship> (raw)
In-Reply-To: <Pine.LNX.4.33.0106052211490.2310-100000@mikeg.weiden.de>
In-Reply-To: <Pine.LNX.4.33.0106052211490.2310-100000@mikeg.weiden.de>

On Tuesday 05 June 2001 23:00, Mike Galbraith wrote:
> On Tue, 5 Jun 2001, Benjamin C.R. LaHaise wrote:
> > Swapping early causes many more problems than swapping late as
> > extraneous seeks to the swap partiton severely degrade performance.
>
> That is not the case here at the spot in the performance curve I'm
> looking at (transition to throughput).
>
> Does this mean the block layer and/or elevator is having problems? 
> Why would using avaliable disk bandwidth vs letting it lie dormant be
> a generically bad thing?.. this I just can't understand.  The
> elevator deals with seeks, the vm is flat not equipped to do so.. it
> contains such concept.

Clearly, if the spindle a dirty file page belongs to is idle, we have 
goofed.

With process data the situation is a little different because the 
natural home of the data is not the swap device but main memory.  The 
following gets pretty close to the truth: when there is memory 
pressure, if the spindle a dirty process page belongs to is idle, we 
have goofed.

Well, as soon as I wrote those obvious truths I started thinking of 
exceptions, but they are silly exceptions such as:

  - read disk block 0
  - dirty last block of disk
  - dirty 1,000 blocks starting at block 0.

For good measure, delete the file the last block of the disk belongs 
to.  We have just sent the head off on a wild goose chase, but we had 
to work at it.  To handle such a set of events without requiring 
prescience we need to be able to cancel disk writes, but just ignoring 
such oddball situations is the next best thing.

That's all by way of saying I agree with you.

--
Daniel

  reply	other threads:[~2001-06-05 22:19 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-06-05  1:04 Comment on patch to remove nr_async_pages limit Marcelo Tosatti
2001-06-05  7:38 ` Mike Galbraith
2001-06-05  6:18   ` Marcelo Tosatti
2001-06-05 10:32     ` Mike Galbraith
2001-06-05 11:42       ` Ed Tomlinson
2001-06-05 16:08         ` Zlatko Calusic
2001-06-05 19:21       ` Benjamin C.R. LaHaise
2001-06-05 21:00         ` Comment on patch to remove nr_async_pages limitA Mike Galbraith
2001-06-05 22:21           ` Daniel Phillips [this message]
2001-06-05 16:05     ` Comment on patch to remove nr_async_pages limit Zlatko Calusic
2001-06-09  3:09       ` Rik van Riel
2001-06-09  6:07         ` Mike Galbraith
2001-06-05 15:57   ` Zlatko Calusic
2001-06-05 15:56 ` Zlatko Calusic

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=01060600213307.00553@starship \
    --to=phillips@bonn-fries.net \
    --cc=blah@kvack.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=marcelo@conectiva.com.br \
    --cc=mikeg@wen-online.de \
    --cc=zlatko.calusic@iskon.hr \
    /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;
as well as URLs for NNTP newsgroup(s).