public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrea Arcangeli <andrea@suse.de>
To: William Lee Irwin III <wli@holomorphy.com>,
	Andrew Morton <akpm@digeo.com>,
	Norman Gaywood <norm@turing.une.edu.au>,
	linux-kernel@vger.kernel.org
Subject: Re: Maybe a VM bug in 2.4.18-18 from RH 8.0?
Date: Fri, 6 Dec 2002 03:28:53 +0100	[thread overview]
Message-ID: <20021206022853.GJ1567@dualathlon.random> (raw)
In-Reply-To: <20021206021559.GK9882@holomorphy.com>

On Thu, Dec 05, 2002 at 06:15:59PM -0800, William Lee Irwin III wrote:
> On Fri, Dec 06, 2002 at 02:44:29AM +0100, Andrea Arcangeli wrote:
> > Or it hurts when you can't allocate an inode because such 100M are in
> > pagetables on a 64G box and you still have 60G free of highmem.
> 
> This is the zone vs. zone watermark stuff that penalizes/fails
> allocations made with a given GFP mask from being satisfied by
> fallback. This is largely old news wrt. various kinds of inability
> to pressure those ZONE_NORMAL (maybe also ZONE_DMA) consumers.
> 
> Admission control for fallback is valuable, sure. I suspect the
> question akpm raised is about memory utilization. My own issues are
> centered around allocations targeted directly at ZONE_NORMAL,
> which fallback prevention does not address, so the watermark patch
> is not something I'm personally very concerned about.

you must be very concerned about it too.

If you don't have the fallback prevention all your efforts around the
allocations targeted directoy zone normal will be completely worthless.

Either that or you want to drop ZONE_NORMAL enterely because it means
nothing uses zone-normal dynamically anymore (ZONE_NORMAL seen as a
place that is directly mapped, not necessairly always 32bit dma
capable).

> 64GB isn't getting any testing that I know of; I'd hold off until
> someone's actually stood up and confessed to attempting to boot
> Linux on such a beast. Or until I get some more RAM. =)

64GB is an example, a good example for this thing, but a 16G machine or
a 4G machine can run in the very same issues. As said just swapoff -a
and malloc(1G) and such 1G is all ZONE_NORMAL before you could allocate
enough inodes for your workload. Or alloc 1G of pagetables by setting
everything protnone, and sugh 1G of pagetables goes in zone-normal
because the highmem is filled by cache. Choose whatever is your
preferred example of real life bug fixed by the lowmem-reservation patch
that is absolutely necessary to run stable on a big box with normal zone
and highmem (not only a 64G box).

The only place where you must not be concerned about these fixes are the
64bit archs.

Andrea

  reply	other threads:[~2002-12-06  2:21 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-06  0:13 Maybe a VM bug in 2.4.18-18 from RH 8.0? Norman Gaywood
2002-12-06  1:00 ` Andrew Morton
2002-12-06  1:17   ` Andrea Arcangeli
2002-12-06  1:34     ` Andrew Morton
2002-12-06  1:44       ` Andrea Arcangeli
2002-12-06  2:15         ` William Lee Irwin III
2002-12-06  2:28           ` Andrea Arcangeli [this message]
2002-12-06  2:41             ` William Lee Irwin III
2002-12-06  5:25               ` Andrew Morton
2002-12-06  5:48                 ` Andrea Arcangeli
2002-12-06  6:14                   ` William Lee Irwin III
2002-12-06  6:55                   ` Andrew Morton
2002-12-06  7:14                     ` GrandMasterLee
2002-12-06  7:25                       ` Andrew Morton
2002-12-06  7:34                         ` GrandMasterLee
2002-12-06  7:51                           ` Andrew Morton
2002-12-06 11:37                             ` Christoph Hellwig
2002-12-06 16:19                             ` GrandMasterLee
2002-12-06 14:57                     ` Andrea Arcangeli
2002-12-06 15:12                       ` William Lee Irwin III
2002-12-06 23:32                         ` Andrea Arcangeli
2002-12-06 23:45                           ` William Lee Irwin III
2002-12-06 23:57                             ` Andrea Arcangeli
2002-12-06  6:00                 ` William Lee Irwin III
2002-12-06 22:28               ` Andrea Arcangeli
2002-12-06 23:21                 ` William Lee Irwin III
2002-12-06 23:50                   ` Andrea Arcangeli
2002-12-07  0:30                     ` William Lee Irwin III
2002-12-07  0:01                   ` Andrew Morton
2002-12-07  0:21                     ` William Lee Irwin III
2002-12-07  0:30                       ` Andrew Morton
2002-12-07  2:19                       ` Alan Cox
2002-12-07  1:46                         ` William Lee Irwin III
2002-12-07  1:56                           ` Andrea Arcangeli
2002-12-07  2:31                           ` Alan Cox
2002-12-07  2:09                             ` William Lee Irwin III
2002-12-07  0:22                     ` Andrea Arcangeli
2002-12-07  0:35                       ` Andrew Morton
2002-12-07  0:46                     ` William Lee Irwin III
2002-12-07 10:55                     ` Arjan van de Ven
2002-12-06 10:36           ` Arjan van de Ven
2002-12-06 14:23             ` William Lee Irwin III
2002-12-06 15:12               ` William Lee Irwin III
2002-12-06 22:34                 ` Andrea Arcangeli
2002-12-07 18:27                   ` Eric W. Biederman
2002-12-06  1:08 ` Andrea Arcangeli
     [not found] <mailman.1039133948.27411.linux-kernel2news@redhat.com>
2002-12-06  0:35 ` Pete Zaitcev
2002-12-06  1:27   ` Norman Gaywood
2002-12-06 12:48     ` Rik van Riel

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=20021206022853.GJ1567@dualathlon.random \
    --to=andrea@suse.de \
    --cc=akpm@digeo.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=norm@turing.une.edu.au \
    --cc=wli@holomorphy.com \
    /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