Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756588AbYG3WW1 (ORCPT ); Wed, 30 Jul 2008 18:22:27 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751496AbYG3WWT (ORCPT ); Wed, 30 Jul 2008 18:22:19 -0400 Received: from rv-out-0506.google.com ([209.85.198.236]:22097 "EHLO rv-out-0506.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750967AbYG3WWS (ORCPT ); Wed, 30 Jul 2008 18:22:18 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=LbEO+6MJTEAww9/BpIbnJplTsupaptnZfqM5eb7s2MU8YONaM5Pqk+tYmjiMT6QDTB w6TkQx8kvyHvSBGcJdT4SkZw1a8z9xOCS+WDrXZ/whFrB/HZAicHIpFSB9+5cIioXoky h5Z0RGkntvpmDNIO2ZN5D8NFJxSrdGHWvQJQo= Message-ID: <84144f020807301522r7fb97bfehe0fcdceef10477b9@mail.gmail.com> Date: Thu, 31 Jul 2008 01:22:17 +0300 From: "Pekka Enberg" To: "Linus Torvalds" Subject: Re: [RFC PATCH] greatly reduce SLOB external fragmentation Cc: "Matt Mackall" , "Christoph Lameter" , "Ingo Molnar" , "Hugh Dickins" , "Andi Kleen" , "Peter Zijlstra" , "Linux Kernel Mailing List" , vegard.nossum@gmail.com, hannes@saeurebad.de In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1199906151.6245.57.camel@cinder.waste.org> <1199919548.6245.74.camel@cinder.waste.org> X-Google-Sender-Auth: 5bac12e3bbce91e7 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1869 Lines: 39 Hi Linus, On Thu, Jul 31, 2008 at 1:00 AM, Linus Torvalds wrote: > I'm happy to hear that the thing worked, but I'm not sure how happy I > should be about yet _another_ allocator. Will it ever end? Oh, I didn't suggest this for merging. Just thought you'd be interested to know that best-fit doesn't really do that much better than what we have in the tree now. (Well, I was kinda hoping you'd tell me why my implementation is wrong and you were right all along.) On Thu, Jul 31, 2008 at 1:00 AM, Linus Torvalds wrote: > But seriously, it looks simple and small enough, so in that sense there > doesn't seem to be a problem. But I really don't look forward to another > one of these, at least not without somebody deciding that yes, we can > prune one of the old ones as never being better. Hmm? I think the current situation is bit unfortunate. SLOB doesn't want cater for everybody (and probably can't do that either), SLAB sucks for NUMA and embedded, and SLUB is too much of a "memory pig" (although much less so than SLAB) to replace SLOB and it has that TPC regression we don't have a test case for. So while SLAB is (slowly) on it's way out, we really don't have a strategy for SLOB/SLUB. I'm trying to come up with something that's memory efficient first and then try to tune that for SMP and NUMA. Looking at how tuned the fast-paths of SLAB and SLUB are (due to the design), it seems unlikely that we can come up with anything that could compete with them. But that doesn't mean we can't have fun trying ;-). Pekka -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/