linux-kernel - Re: [GIT PULL] scheduler fixes

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]

Date:	Mon, 18 May 2009 15:06:26 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Ingo Molnar <mingo@...e.hu>
cc:	"H. Peter Anvin" <hpa@...or.com>,
	Pekka Enberg <penberg@...helsinki.fi>,
	Yinghai Lu <yinghai@...nel.org>,
	Jeff Garzik <jgarzik@...ox.com>,
	Alexander Viro <viro@....linux.org.uk>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [GIT PULL] scheduler fixes

On Mon, 18 May 2009, Ingo Molnar wrote:
> 
> ok. I've queued it up for .31, with your Acked-by. (which i assume 
> your reply implies?)

Yes.

> > I hate that stupid bootmem allocator. I suspect we seriously 
> > over-use it, and that we _should_ be able to do the SL*B init 
> > earlier.
> 
> Hm, tempting thought - not sure how to pull it off though.

As far as I can recall, one of the things that historically made us want 
to use the bootmem allocator even relatively late was that the real SLAB 
allocator had to wait until all the node information etc was initialized. 

That's pretty damn late. And I wonder if SLUB (and SLOB) might not need a 
lot less initialization, and work much earlier. Something like that might 
be the final nail in the coffin for SLAB, and convince me to just say 
'we don't support it any more".

That said, for the case of things like 'static_sched_group' and 
'static_sched_domain', the problem might well be not just about the 
allocation itself, but simply about the use of those variables. Maybe they 
themselves are needed before we've done all the CPU setup?

> One of the biggest user of bootmem is the mem_map[] hierarchies and 
> the page allocator bitmaps. Not sure we can get rid of bootmem there 
> - those areas are really large, physical memory is often fragmented 
> and we need a good NUMA sense for them as well.

I think that's the _valid_ kind of use of a bootmem allocator.

But for something like the scheduler data structures? Not so much.

		Linus
--
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/