From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754456AbZERWIO (ORCPT ); Mon, 18 May 2009 18:08:14 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752918AbZERWIA (ORCPT ); Mon, 18 May 2009 18:08:00 -0400 Received: from smtp1.linux-foundation.org ([140.211.169.13]:42780 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751992AbZERWH7 (ORCPT ); Mon, 18 May 2009 18:07:59 -0400 Date: Mon, 18 May 2009 15:06:26 -0700 (PDT) From: Linus Torvalds X-X-Sender: torvalds@localhost.localdomain To: Ingo Molnar cc: "H. Peter Anvin" , Pekka Enberg , Yinghai Lu , Jeff Garzik , Alexander Viro , Rusty Russell , Linux Kernel Mailing List , Andrew Morton , Peter Zijlstra Subject: Re: [GIT PULL] scheduler fixes In-Reply-To: <20090518202031.GA26549@elte.hu> Message-ID: References: <20090518142707.GA24142@elte.hu> <20090518164921.GA6903@elte.hu> <20090518170909.GA1623@elte.hu> <20090518190320.GA20260@elte.hu> <20090518202031.GA26549@elte.hu> User-Agent: Alpine 2.01 (LFD 1184 2008-12-16) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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