[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CALF0-+UCS+9ypoh+_sFzFcAB2b7Gc=Dj-USJvU=LWa7AdJo3ng@mail.gmail.com>
Date: Fri, 30 Nov 2012 17:43:07 -0300
From: Ezequiel Garcia <elezegarcia@...il.com>
To: dedekind1@...il.com,
richard -rw- weinberger <richard.weinberger@...il.com>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-mtd@...ts.infradead.org,
David Woodhouse <dwmw2@...radead.org>,
Tim Bird <tim.bird@...sony.com>,
Michael Opdenacker <michael.opdenacker@...e-electrons.com>,
Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>
Subject: Re: [RFC/PATCH 0/1] ubi: Add ubiblock driver
Hi Artem,
Thanks for the taking the time to answer.
On Fri, Nov 30, 2012 at 8:08 AM, Artem Bityutskiy <dedekind1@...il.com> 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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists