[PATCH 1/1] ubi: Introduce block devices for UBI volumes
Willy Tarreau
w at 1wt.eu
Mon Feb 10 03:37:28 EST 2014
On Mon, Feb 10, 2014 at 10:24:12AM +0200, Artem Bityutskiy wrote:
> On Mon, 2014-02-10 at 05:12 -0300, Ezequiel Garcia wrote:
> > On Mon, Feb 10, 2014 at 08:53:14AM +0100, Richard Weinberger wrote:
> > > Am 10.02.2014 02:29, schrieb Ezequiel Garcia:
> > > >>> +
> > > >>> + mutex_lock(&dev->vol_mutex);
> > > >>> + res = do_ubiblock_request(dev, req);
> > > >>> + mutex_unlock(&dev->vol_mutex);
> > > >>
> > > >> This means that you can never do parallel IO?
> > > >>
> > > >
> > > > Indeed. Feel free to prepare a follow-up patch improving it,
> > > > once this is merged.
> > >
> > > Sorry, this is a very lame argument.
> > >
> > > You need to describe why your application design has this flaw.
> >
> > Not at all. It's perfectly fine to merge a feature with a simple
> > implementation and improve it progressively. In fact, I've explicitly
> > chosen the simplest implementation whenever possible. We can always
> > get back here and improve the performance.
>
> The NAND part of the MTD layer serializes all the I/O, so probably it is
> OK. May be needs to be documented, though. May be a comment in the code
> would be nice to have too.
I think so as well. Seeing how slow my NAND is on the mirabox (about
14 MB/s), I think that whatever level of parallelism we could have
would not make anything better since we're always waiting for the
device anyway. Also, such systems are generally designed to limit
access as much as possible.
Regards,
Willy
More information about the linux-mtd
mailing list