All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: David Rientjes <rientjes@google.com>
Cc: Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Casey Dahlin <cdahlin@redhat.com>,
	x86@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [patch] x86: allow ZONE_DMA to be configurable
Date: Thu, 14 Oct 2010 15:32:23 -0700	[thread overview]
Message-ID: <20101014153223.a710d70c.akpm@linux-foundation.org> (raw)
In-Reply-To: <alpine.DEB.2.00.1010141509270.3696@chino.kir.corp.google.com>

On Thu, 14 Oct 2010 15:15:28 -0700 (PDT)
David Rientjes <rientjes@google.com> wrote:

> On Thu, 14 Oct 2010, Andrew Morton wrote:
> 
> > > ZONE_DMA is unnecessary for a large number of machines that do not
> > > require addressing in the lower 16MB of memory because they do not use
> > > ISA devices with 16-bit address registers (plus one page byte register).
> > > 
> > > This patch allows users to disable ZONE_DMA for x86 if they know they
> > > will not be using such devices with their kernel.
> > > 
> > > This prevents the VM from unnecessarily reserving a ratio of memory
> > > (defaulting to 1/256th of system capacity) with lowmem_reserve_ratio
> > > for such allocations when it will never be used.
> > > 
> > 
> > I wonder how hard it would be to do this at runtime, probably with a
> > boot parameter.
> > 
> 
> A "no_zone_dma" boot parameter wouldn't allow us to achieve the text or 
> data savings that we see from disabling all three options in question 
> here.

True, but doing it at runtime is vastly more user-friendly.  Distros
aren't doing to double the number of kernels they package for this
option!

Of course, we could do both.

> Hot-adding ZONE_DMA at runtime would be possible but there's no guarantee 
> that memory hasn't fully been used by the time you do it, so it disregards 
> lowmem_reserve_ratio unless you migrate everything, which has a dependency 
> on it being movable.
> 
> > I'd be a little concerned at the effects of this on page reclaim and
> > the page allocator - it might expose weird pre-existing bugs or
> > inefficiencies.  But we can cross that bridge when we fall off it, I
> > guess.
> > 
> 
> We've run with it for a couple years, we can even undefine __GFP_DMA to 
> find allocations that we compile into the kernel to ensure we don't have a 
> requirement for the zone.

"we" is google, I assume.

>  Perhaps only define the gfp flag when we have 
> CONFIG_ZONE_DMA and break users' builds until they disable options that 
> require it

That sounds a good idea.

What happens in the current patch if someone passes __GFP_DMA when
CONFIG_ZONE_DMA=n?  ENOMEM?  Perhaps it should WARN() as well.

> (or enable CONFIG_ZONE_DMA)?

hm.  It'd be better to make all the drivers depend on ZONE_DMA.  Good
luck with that :)

> It would be great if we could do "select ZONE_DMA" for all options that 
> require it, though.

  reply	other threads:[~2010-10-14 22:33 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-14  0:15 [patch] x86: allow ZONE_DMA to be configurable David Rientjes
2010-10-14  0:23 ` H. Peter Anvin
2010-10-14  0:42   ` David Rientjes
2010-10-14  0:44     ` H. Peter Anvin
2010-10-14  0:49       ` David Rientjes
2010-10-14  1:21         ` H. Peter Anvin
2010-10-14  1:48           ` David Rientjes
2010-10-14  2:38             ` H. Peter Anvin
2010-10-14  3:55               ` David Rientjes
2010-10-14  4:37             ` H. Peter Anvin
2010-10-14  4:46               ` David Rientjes
2010-10-14 15:38                 ` H. Peter Anvin
2010-10-14 16:00                   ` Pekka Enberg
2010-10-14 17:44                     ` H. Peter Anvin
2010-10-14 18:34                       ` Ingo Molnar
2010-10-14 19:35                         ` Andrew Morton
2010-10-14 20:40                           ` H. Peter Anvin
2010-10-15  3:03                             ` Ingo Molnar
2010-10-15  4:45                               ` H. Peter Anvin
2010-10-15  9:05                               ` David Rientjes
2010-10-15 15:06                                 ` H. Peter Anvin
2010-10-14 22:08                   ` David Rientjes
2010-10-14  8:10 ` Andrew Morton
2010-10-14  8:32   ` KOSAKI Motohiro
2010-10-14 22:15   ` David Rientjes
2010-10-14 22:32     ` Andrew Morton [this message]
2010-10-15  3:10       ` Ingo Molnar
2010-10-15  9:11         ` David Rientjes
2010-10-15  9:09       ` David Rientjes
2010-10-21 14:56         ` Christoph Lameter

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=20101014153223.a710d70c.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=cdahlin@redhat.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=rientjes@google.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /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.