linux-kernel - Re: [PATCH 1/7] mm: introduce simple_malloc()/simple

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: <20081116135130.5e8b4e13@infradead.org>
Date:	Sun, 16 Nov 2008 13:51:30 -0800
From:	Arjan van de Ven <arjan@...radead.org>
To:	"Dave Airlie" <airlied@...il.com>
Cc:	"David Miller" <davem@...emloft.net>, laijs@...fujitsu.com,
	akpm@...ux-foundation.org, menage@...gle.com,
	kamezawa.hiroyu@...fujitsu.com, balbir@...ux.vnet.ibm.com,
	jens.axboe@...cle.com, jack@...e.cz, jes@....com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/7] mm: introduce simple_malloc()/simple_free()

On Mon, 17 Nov 2008 07:39:55 +1000
"Dave Airlie" <airlied@...il.com> wrote:

> On Mon, Nov 17, 2008 at 4:57 AM, Arjan van de Ven
> <arjan@...radead.org> wrote:
> > On Sun, 16 Nov 2008 00:19:26 -0800 (PST)
> > David Miller <davem@...emloft.net> wrote:
> >
> >> From: Arjan van de Ven <arjan@...radead.org>
> >> Date: Sat, 15 Nov 2008 20:52:29 -0800
> >>
> >> > On Sun, 16 Nov 2008 12:33:15 +0800
> >> > Lai Jiangshan <laijs@...fujitsu.com> wrote:
> >> >
> >> > >
> >> > > some subsystem needs vmalloc() when required memory is large.
> >> > > but current kernel has not APIs for this requirement.
> >> > > this patch introduces simple_malloc() and simple_free().
> >> >
> >> > I kinda really don't like this approach. vmalloc() (and
> >> > especially, vfree()) is a really expensive operation, and
> >> > vmalloc()'d memory is also slower (due to tlb pressure).
> >> > Realistically, people should try hard to use small datastructure
> >> > instead....
> >>
> >> This is happening in many places, already, for good reason.
> >>
> >> There are lots of places where we can't (core hash tables, etc.)
> >> and we want NUMA spreading and reliable allocation, and thus
> >> vmalloc it is.
> >
> > vmalloc() isn't 100% evil; for truely long term stuff it's
> > sometimes a quite reasonable solution.
> >
> > There are some issues with it still: the vmalloc() space is shared
> > with ioremap, modules and others and it's not all that big on 32
> > bit; on x86 you could well end up with only 64Mb total (after
> > taking out the various ioremap's etc).
> >
> > Yes there's places where it's then totally fine to dip into this
> > space at boot/init time. You mention a few very good users.
> > (There's still the tlb miss cost on use but on modern cpus a tlb
> > miss is actually quite cheap)
> >
> > But this doesn't make vmalloc() the magic bullet that solves the "oh
> > Linux can't allocate large chunks of memory" problem. Specifically
> > in driver space for things that get ported from other OSes.
> 
> So we keep the duplicated code? or we just audit new callers.... I
> think this patch
> makes it easier to spot new callers doing something stupid. As davem
> said we duplicate
> this code all over the place, so for that reason along a simple
> wrapper makes things a lot
> easier, and also possibly a lot easier to change in the future to a
> new non-sucky API.
> 
> So I'm all for it maybe with a non simple name.
> 

I would go further than this.

Make the code just use vmalloc(). Period.

But then make vmalloc() smart and try do a direct mapping allocation
first, before falling back to a virtual mapping. (and based on size it
wouldn't even try it for just big things)



-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org
--
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/