linux-kernel - Re: [patch] x86: allow ZONE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20101015031014.GC9640@elte.hu>
Date:	Fri, 15 Oct 2010 05:10:14 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	David Rientjes <rientjes@...gle.com>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Casey Dahlin <cdahlin@...hat.com>, x86@...nel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [patch] x86: allow ZONE_DMA to be configurable


* Andrew Morton <akpm@...ux-foundation.org> wrote:

> On Thu, 14 Oct 2010 15:15:28 -0700 (PDT)
> David Rientjes <rientjes@...gle.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!

Strongly agreed!

Can we automate it perhaps? Drivers could express their zone needs, and 
perhaps we can free up the zone if there's no relevant driver loaded by 
the time we have booted up? If a hotplug driver arrives later on, is the 
MM good enough for us to be able to reinstate the zone dynamically?

Since we allocate top-down generally, the chance that the low zone is 
100% filled up with pinned, unmovable kmalloc buffers is small, so this 
solution could be practical - even if much of that zone is utilized 
already. These low allocations are pretty small typically.

We could also shrink the zone to an emergency amount, say 1MB, instead 
of zapping it completely, or so.

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/