From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751568AbdB1WPT (ORCPT ); Tue, 28 Feb 2017 17:15:19 -0500 Received: from mail-pg0-f65.google.com ([74.125.83.65]:36618 "EHLO mail-pg0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751099AbdB1WPR (ORCPT ); Tue, 28 Feb 2017 17:15:17 -0500 Date: Tue, 28 Feb 2017 14:12:45 -0800 From: Dmitry Torokhov To: Geert Uytterhoeven Cc: Mark Brown , linux-spi , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH v2 2/3] spi: allocate spi_board_info entries one by one Message-ID: <20170228221245.GL20776@dtor-ws> References: <20170228041857.13292-1-dmitry.torokhov@gmail.com> <20170228041857.13292-3-dmitry.torokhov@gmail.com> <20170228091650.eiypppxblfhh33pb@sirena.org.uk> <20170228182417.GA20776@dtor-ws> <20170228185455.mdmvuc232chlveve@sirena.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 28, 2017 at 09:15:12PM +0100, Geert Uytterhoeven wrote: > On Tue, Feb 28, 2017 at 7:54 PM, Mark Brown wrote: > > On Tue, Feb 28, 2017 at 10:24:17AM -0800, Dmitry Torokhov wrote: > >> On Tue, Feb 28, 2017 at 09:16:50AM +0000, Mark Brown wrote: > >> > On Mon, Feb 27, 2017 at 08:18:56PM -0800, Dmitry Torokhov wrote: > >> > > Lists of spi_board_info entries registered with spi_register_board_info() > >> > > can be quite long; instead of forcing memory allocator find contagious > > > >> > Do you have numbers on that? > > > >> Hm, so the largest array seems to be in > >> arch/blackfin/mach-bf537/boards/stamp.c at max of 43 entries. The new > >> board info is ether 60 or 72 bytes, so we get 2 or 3K table. Not above > >> page, but still could be packed I think. > > > > Oh wow, that's impressively large. Still not sure the optimization is > > particularly worth it though, it's small change in the grand scheme of > > things. OTOH it's a small change. > > Given this is done during early boot, what's the probability of not having > sufficient contiguous memory? > > >> If we decide that we want to keep single chunk I'll just change the > >> allocation to kcalloc. Let me know. > > > > I'd be inclined to do that because it requires less thinking about the > > value of what should be a very small optimization either way but > > whatever :) > > Tada... > > commit f9bdb7fdd2cac17bdc9c344b6036e6939fa087cd > Author: Markus Elfring > Date: Fri Jan 13 12:28:04 2017 +0100 > > spi: Use kcalloc() in spi_register_board_info() Or even kmalloc_array() as zeroing out memory is not needed. But I'll let Mark sort it out and drop my patch #2. Thanks. -- Dmitry