From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753710AbZEYE6p (ORCPT ); Mon, 25 May 2009 00:58:45 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750896AbZEYE6i (ORCPT ); Mon, 25 May 2009 00:58:38 -0400 Received: from terminus.zytor.com ([198.137.202.10]:41138 "EHLO terminus.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750852AbZEYE6h (ORCPT ); Mon, 25 May 2009 00:58:37 -0400 Message-ID: <4A1A241D.603@zytor.com> Date: Sun, 24 May 2009 21:52:45 -0700 From: "H. Peter Anvin" User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Ingo Molnar CC: Yinghai Lu , Pekka J Enberg , Linus Torvalds , Jeff Garzik , Alexander Viro , Rusty Russell , Linux Kernel Mailing List , Andrew Morton , Peter Zijlstra Subject: Re: [GIT PULL] scheduler fixes References: <20090518164921.GA6903@elte.hu> <20090518170909.GA1623@elte.hu> <20090518190320.GA20260@elte.hu> <20090518202031.GA26549@elte.hu> <4A199327.5030503@kernel.org> <20090525025353.GA2580@elte.hu> In-Reply-To: <20090525025353.GA2580@elte.hu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Ingo Molnar wrote: > > Would it be possible to restructure things to move kmalloc init to > before IRQ init as well? We have a couple of uglinesses there too. > > Conceptually, memory should be the first thing set up in general, in > a kernel. It does not need IRQs, timers, the scheduler or any of the > IO facilities and abstractions. All of them need memory though - and > as Linux scales to more and more hardware via the same single image, > so will we get more and more dynamic concepts like cpumask_var_t and > sparse-irqs, which want to allocate very early. > > setup_arch() is one huge function that sets up all architecture > details at once - but if we split a separate setup_arch_mem() out of > it, and left the rest in setup_arch (and moved it further down), we > could remove much of bootmem (especially the ugly uses). > > This might even be doable realistically, and we could thus librarize > bootmem and eliminate it from x86 at least. Perhaps. > The only thing that might make sense to set up before memory might be exceptions (as opposed to interrupts), but both of those should be doable very very early. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.