Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933699Ab2K3Usk (ORCPT ); Fri, 30 Nov 2012 15:48:40 -0500 Received: from mail-ia0-f179.google.com ([209.85.210.179]:39139 "EHLO mail-ia0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752898Ab2K3Usi (ORCPT ); Fri, 30 Nov 2012 15:48:38 -0500 X-Greylist: delayed 330 seconds by postgrey-1.27 at vger.kernel.org; Fri, 30 Nov 2012 15:48:38 EST MIME-Version: 1.0 In-Reply-To: <1354273697.30168.87.camel@sauron.fi.intel.com> References: <1354273697.30168.87.camel@sauron.fi.intel.com> Date: Fri, 30 Nov 2012 17:43:07 -0300 Message-ID: Subject: Re: [RFC/PATCH 0/1] ubi: Add ubiblock driver From: Ezequiel Garcia To: dedekind1@gmail.com, richard -rw- weinberger Cc: Linux Kernel Mailing List , linux-mtd@lists.infradead.org, David Woodhouse , Tim Bird , Michael Opdenacker , Thomas Petazzoni Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1671 Lines: 53 Hi Artem, Thanks for the taking the time to answer. On Fri, Nov 30, 2012 at 8:08 AM, Artem Bityutskiy wrote: > >> I don't know how many ubi volumes a user typically creates, but I >> expect not to be too many. > > I think I saw something like 8-10 in some peoples' reports. > Mmm, that's more than I've expected. [...] > >> This cache is 1-LEB bytes, vmalloced at open() and freed at release(). > > Is it per-block device? Yes. But notice the vmalloced cache is freed on release(). So, an unused ubiblock won't allocate it. >Then I am not sure it is a good idea to > automatically create them for every volume... > Given that ubiblock is workqueue based I believe there isn't any performance penalty in creating many instances. Regarding memory footprint: we should consider how much does it cost to create an ubiblock device, plus the underlying gendisk, request queue, etc. If people is partitioning its ubi devices in 8-10 volumes, then I'm not too sure if we want to create a block device per-volume automatically. Not because of the cache -again, if an ubiblock is unused it won't allocate any- but because of overall unnecessary bloatness. The main idea behind auto-creation is that, IMHO, ubi ecosystem already has its own rather large set of userspace tools, I'm against adding yet another one. I'm gonna keep playing with this and come up with the long promise numbers. Ezequiel -- 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/