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]

Message-ID: <alpine.LFD.2.01.0905240947490.3435@localhost.localdomain>
Date:	Sun, 24 May 2009 11:18:03 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Pekka J Enberg <penberg@...helsinki.fi>
cc:	Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
	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 Sun, 24 May 2009, Pekka J Enberg wrote:
>
> Ingo, here's a patch that boots UMA+SMP+SLUB x86-64 kernel on qemu all 
> the way to userspace. It probably breaks bunch of things for now but 
> something for you to play with if you want.

Just looking at the patch (not actually trying it out in any way or 
looking at some bigger context), this absolutely looks like the right 
direction to go in.

Our order in init/main.c is largely totally historical, and I think it 
makes tons of sense to move the memory allocation initialization up much 
earlier. 

In fact, it would be nice to perhaps try to move it even earlier. Now you 
moved it to before the scheduler init (good!), but I do wonder if it could 
be moved up to even before the setup_per_cpu_areas() etc crud. 

I realize that the allocator wants to use the per-CPU area, but if we have 
just the boot CPU area set up statically at that point, since it's only 
the boot CPU running, maybe we could do those per-cpu area allocations 
without the bootmem allocator too?

But even just getting bootmem out of the scheduler setup is a big 
improvement, I think. So this patch looks very promising as is.

Did you test whether the other allocators were ok with this too?

		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/