linux-kernel - Re: [PATCH RFC 0/2] mempool based chained scatterlist alloc/free api api

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]

Date:	Wed, 16 Mar 2016 09:26:31 +0100
From:	Christoph Hellwig <hch@....de>
To:	James Bottomley <James.Bottomley@...senPartnership.com>
Cc:	Ming Lin <mlin@...nel.org>, linux-kernel@...r.kernel.org,
	linux-scsi@...r.kernel.org, Christoph Hellwig <hch@....de>
Subject: Re: [PATCH RFC 0/2] mempool based chained scatterlist alloc/free
	api api

On Tue, Mar 15, 2016 at 04:12:03PM -0700, James Bottomley wrote:
> motion.  If you add in one patch and remove in another the code motion
> trackers don't see it.

Agreed, having the move in a single patch would be nice.

> Thirdly, are you sure the pool structure for NVMe should be the same as
> for SCSI?  We don't do buddy pools for 1,2 or 4 entry transactions in
> SCSI just basically because of heuristics, but the packetised io
> characteristics of NVMe make single entry lists more likely for it,
> don't they?

Not really.  NVMe doesn't really do packetized I/O.  And while people
were setting all kinds of nomerge flags early on we're getting rid
of them and are seeing similar I/O patterns to fast SCSI devices
now.

NVMe over PCIe still uses the crazy PRPs by default, which aren't
very suitable for this allocator (someone will have to come up
with a good mempool for it eventually, though), but we're developing
a set of new drivers transporting NVMe command which use SGLs very
similar to most SCSI controllers, so using the same SGL allocator
is a very natural choice.