mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andrea Arcangeli <andrea@suse.de>
To: Andrew Morton <akpm@zip.com.au>
Cc: rwhron@earthlink.net, linux-kernel@vger.kernel.org,
	marcelo@conectiva.com.br
Subject: Re: Linux 2.4.19-pre5
Date: Mon, 1 Apr 2002 03:24:00 +0200	[thread overview]
Message-ID: <20020401032400.O1331@dualathlon.random> (raw)
In-Reply-To: <20020330135333.A16794@rushmore> <3CA616B2.1F0D8A76@zip.com.au>

On Sat, Mar 30, 2002 at 11:49:06AM -0800, Andrew Morton wrote:
> That's rather irrational, because most of the dirty buffers
> will be in ZONE_HIGHMEM.  So hmmmm.  Probably we should go

You're right it's not the best, but it's intentional and correct. We've
just one single balance_dirty(void) and it has to balance metadata and
data, data will be in highmem too, but metadata will be in normal zone
for most filesystems (even ext[23], modulo direntries for ext2) and
that's why we've to consider only the normal zone as a certain target of
the allocation, to be sure not to overstimate for metadata. OTOH in
particular to take full advantage of the point of view watermarks it
would be really nicer to say if we've to balance_dirty on the normal
zone or on the highmem zone (currently we could overstimate a bit the
amount of ram we can take from the normal zone with an highmem
allocation (we look at the the high watermark from the "normal" point of
view), but OTOH we always understimate the amount of potential highmem
free), so the current way is mostly ok for now (not a showstopper). To
improve that bit we simply need a kind of "zone" argument to
balance_dirty() API, done that the other changes should be a formality.

Andrea

  parent reply	other threads:[~2002-04-01  1:24 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-03-30 18:53 rwhron
2002-03-30 19:49 ` Andrew Morton
2002-03-30 21:33   ` Randy Hron
2002-03-30 21:42     ` Ed Sweetman
2002-03-30 22:25       ` Randy Hron
2002-03-30 23:48         ` Ed Sweetman
2002-03-31 12:42           ` Randy Hron
2002-03-31 20:05             ` Ed Sweetman
2002-03-31 23:11               ` Randy Hron
2002-03-31  6:52   ` Andrew Morton
2002-04-01  0:36     ` Andrea Arcangeli
2002-04-01  1:24   ` Andrea Arcangeli [this message]
  -- strict thread matches above, loose matches on Subject: below --
2002-04-04  9:08 Tom Holroyd
2002-04-04 19:28 ` Marcelo Tosatti
2002-04-05  4:13   ` Tom Holroyd
2002-04-16 14:49     ` Andrea Arcangeli
2002-04-17  1:22       ` Tom Holroyd
2002-03-29 21:47 Marcelo Tosatti
2002-03-30 20:40 ` Michal Jaegermann
2002-03-30 23:34   ` Keith Owens
2002-03-31  1:41     ` Michal Jaegermann
2002-04-04 19:50 ` Adrian Bunk
2002-04-04 21:41   ` Marcelo Tosatti

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=20020401032400.O1331@dualathlon.random \
    --to=andrea@suse.de \
    --cc=akpm@zip.com.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcelo@conectiva.com.br \
    --cc=rwhron@earthlink.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 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®