* guaranteed progress for NVME commands?
@ 2016-03-22 7:45 Christoph Hellwig
2016-03-22 14:46 ` Keith Busch
0 siblings, 1 reply; 3+ messages in thread
From: Christoph Hellwig @ 2016-03-22 7:45 UTC (permalink / raw)
Hi All,
in SCSI and other block drivers we go through great pains to only
use mempool backed allocations in the I/O path, so that we can make
guaranteed progress for swap or the writeback daemons. But it seems
like the NVMe driver is using plain kmalloc everywhere and seems to
be getting away with that just for now. Is no one using swap on
NVMe or am I missing a secret trick somewhere?
^ permalink raw reply [flat|nested] 3+ messages in thread
* guaranteed progress for NVME commands?
2016-03-22 7:45 guaranteed progress for NVME commands? Christoph Hellwig
@ 2016-03-22 14:46 ` Keith Busch
2016-03-22 17:57 ` Keith Busch
0 siblings, 1 reply; 3+ messages in thread
From: Keith Busch @ 2016-03-22 14:46 UTC (permalink / raw)
On Tue, Mar 22, 2016@12:45:31AM -0700, Christoph Hellwig wrote:
> in SCSI and other block drivers we go through great pains to only
> use mempool backed allocations in the I/O path, so that we can make
> guaranteed progress for swap or the writeback daemons. But it seems
> like the NVMe driver is using plain kmalloc everywhere and seems to
> be getting away with that just for now. Is no one using swap on
> NVMe or am I missing a secret trick somewhere?
I believe swap reads and writes single pages, right? We only kmalloc if
we're transferring more than two pages.
... well, mostly. There are caveats if the host page size is greater than
the device's, but I'm not sure why the driver is even considering that.
The transfer size doesn't matter; only nr_phys_segments should determine how
many elements the nvme_iod sgl needs to have.
Anyway, our IO path's only malloc is the nvme_iod scatter list if it
doesn't fit inline. Is that sufficient for progress, or do you think
we need to follow a different example?
^ permalink raw reply [flat|nested] 3+ messages in thread
* guaranteed progress for NVME commands?
2016-03-22 14:46 ` Keith Busch
@ 2016-03-22 17:57 ` Keith Busch
0 siblings, 0 replies; 3+ messages in thread
From: Keith Busch @ 2016-03-22 17:57 UTC (permalink / raw)
On Tue, Mar 22, 2016@02:46:16PM +0000, Keith Busch wrote:
> I'm not sure why the driver is even considering that.
> The transfer size doesn't matter; only nr_phys_segments should determine how
> many elements the nvme_iod sgl needs to have.
err, scratch that. The size has to be accounted for when considering
PRP lists, which are unnamed fields in struct nvme_iod.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2016-03-22 17:57 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-03-22 7:45 guaranteed progress for NVME commands? Christoph Hellwig
2016-03-22 14:46 ` Keith Busch
2016-03-22 17:57 ` Keith Busch
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox