From: Andrew Morton <akpm@zip.com.au>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: Dave Hansen <haveblue@us.ibm.com>,
Alexander Viro <viro@math.psu.edu>,
linux-kernel@vger.kernel.org,
"Martin J. Bligh" <Martin.Bligh@us.ibm.com>
Subject: Re: locking in sync_old_buffers
Date: Mon, 22 Apr 2002 15:50:25 -0700 [thread overview]
Message-ID: <3CC493B1.E9877DB4@zip.com.au> (raw)
In-Reply-To: <3CC48D51.3050506@us.ibm.com> <Pine.LNX.4.44.0204221525190.1235-100000@home.transmeta.com>
Linus Torvalds wrote:
>
> ...
> > >http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.8/everything.patch.gz
> > Absolutely. What else does it contain that I should watch out for?
>
> Don't use it on a production machine, but since this is in the 2.5.x
> future, I'd love to hear about not just lock contention but also about
> whether you can see any problems under heavy load.
>
It may choke under metadata-intensive workloads on really
large memory machines. It works fine with 2.5 gigabyte x86,
but 16 gigs may cause problems.
This is because the dirty-memory balancing code doesn't know
that blockdev mappings are restricted to ZONE_NORMAL. The
correct fix for that is, of course, to allow blockdev mappings
to use highmem. That will require methodical picking away at
all the filesystems, and will take some time.
ext2 should be OK because much of its metadata (directories)
are in highmem at present.
-
next prev parent reply other threads:[~2002-04-22 22:51 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-22 21:01 locking in sync_old_buffers Dave Hansen
2002-04-22 22:08 ` Andrew Morton
2002-04-22 22:23 ` Dave Hansen
2002-04-22 22:28 ` Linus Torvalds
2002-04-22 22:50 ` Andrew Morton [this message]
2002-04-23 1:31 ` Alexander Viro
2002-04-23 18:29 ` Dave Hansen
2002-04-22 22:25 ` Martin J. Bligh
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=3CC493B1.E9877DB4@zip.com.au \
--to=akpm@zip.com.au \
--cc=Martin.Bligh@us.ibm.com \
--cc=haveblue@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.com \
--cc=viro@math.psu.edu \
/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