From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benjamin Herrenschmidt Subject: Re: [PATCH 07/31] lmb: Add reserve_lmb/free_lmb Date: Tue, 30 Mar 2010 10:31:31 +1100 Message-ID: <1269905491.7101.40.camel@pasglop> References: <1269830604-26214-1-git-send-email-yinghai@kernel.org> <1269830604-26214-8-git-send-email-yinghai@kernel.org> <1269865322.24620.42.camel@concordia> <4BB0D92C.3010103@kernel.org> <1269901252.2286.11.camel@concordia> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: Received: from gate.crashing.org ([63.228.1.57]:45377 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752971Ab0C2XdO (ORCPT ); Mon, 29 Mar 2010 19:33:14 -0400 In-Reply-To: <1269901252.2286.11.camel@concordia> Sender: linux-arch-owner@vger.kernel.org List-ID: To: michael@ellerman.id.au Cc: Yinghai Lu , Ingo Molnar , Thomas Gleixner , "H. Peter Anvin" , Andrew Morton , David Miller , Linus Torvalds , Johannes Weiner , linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org On Tue, 2010-03-30 at 09:20 +1100, Michael Ellerman wrote: > > But that's my point. You shouldn't need to touch the existing API, and > you shouldn't need to add a new parallel API. You should just be able to > add the logic for doubling the array in the lmb core, and then everyone > gets dynamically expandable lmb. I don't see any reason why we want to > have two APIs. Ack. > > > It seems to me that rather than adding these "special" routines that > > > check for enough space on the way in, instead you should be checking in > > > lmb_add_region() - which is where AFAICS all allocs/frees/reserves > > > eventually end up if they need to insert a new region. > > > > later i prefer to replace lmb_alloc with find_lmb_area + reserve_lmb. > > Why? The existing code has been working for years and is well tested? I still don't totally understand why he needs a find_lmb_area() anyways. It might be justified ... or not. I just want it to be better documented. Cheers, Ben.