linux-kernel - Re: [PATCH] UBI: Block: Add blk-mq support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5456AE72.1010409@nod.at>
Date:	Sun, 02 Nov 2014 23:21:38 +0100
From:	Richard Weinberger <richard@....at>
To:	Ezequiel Garcia <ezequiel.garcia@...e-electrons.com>,
	hch@...radead.org, axboe@...com, dedekind1@...il.com
CC:	dwmw2@...radead.org, computersforpeace@...il.com,
	linux-mtd@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] UBI: Block: Add blk-mq support

Ezequiel,

Am 02.11.2014 um 22:52 schrieb Ezequiel Garcia:
> Maybe you can explain a bit better what's this all about?

In short, blk-mq is the future and the current blk interface will be legacy. :-)
Christoph asked me to convert the MTD block drivers to blk-mq.

> Both the commit that introduces blk-mq and the paper on it talk about
> high IOPS devices, multi-core, NUMA systems. I'm not sure this is the
> case for UBI-based devices.
> 
> Probably some numbers would help us decide. Does the patch increases the
> dynamic memory footprint? Is there any performance benefit?

I did a very rough micro benchmark:

root@(none):~# dd if=/dev/ubiblock0_0 of=/dev/null bs=1M
121+1 records in
121+1 records out
127420416 bytes (127 MB) copied, 1.59056 s, 80.1 MB/s

vs.

root@(none):~# dd if=/dev/ubiblock0_0 of=/dev/null bs=1M
121+1 records in
121+1 records out
127420416 bytes (127 MB) copied, 0.916117 s, 139 MB/s

So, yes there is a performance gain.

> I kind of like the negative diffstat, but the code doesn't look cleaner
> or simpler.
> 
> In other words, we need a good reason before we agree on making this
> "zen style" driver more complex.

After reading my patch again I think we could move ubiblock_read_to_sg()
to kapi.c or io.c. It is rather generic and maybe we can tun more UBI users to
scattergather such that less vmalloc()s are needed.

This would also make the diffstat nicer...

Thanks,
//richard


Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)