On Fri, Jun 1, 2018 at 12:28 PM, Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > On Fri, Jun 01, 2018 at 09:59:03AM -0600, Jens Axboe wrote: >> On 6/1/18 9:57 AM, Adam Manzanares wrote: >> > >> > >> > On 6/1/18 8:41 AM, Jens Axboe wrote: >> >> On 6/1/18 9:38 AM, Adam Manzanares wrote: >> >>> On 5/31/18 10:13 PM, Christoph Hellwig wrote: >> >>>>> +extern int ioprio_check_cap(int ioprio); >> >>>> >> >>>> Which then is implemented in block/ioprio.c, which depends on >> >>>> CONFIG_BLOCK. The code either needs a stub for !CONFIG_BLOCK >> >>>> or moved elsewhere. >> >>> >> >>> My vote would be to move the ioprio code into fs/. At first glance I do >> >>> not see a dependence on the block layer in block/ioprio.c. >> >>> >> >>> Any objections? >> >> >> >> Since it's block ioprio code, I'd prefer a stub instead. >> >> >> > >> > This feature could be used independently from the block layer. We have >> > examples (ATA, hopefully NVME soon) where we are reacting to the ioprio >> > in the device drivers essentially passing the ioprio through the block >> > layer. >> >> It could, yes, but it isn't. As it stands, it's system call support to >> pass in IO priority for what ultimately is block storage. > > I think it'd be interesting if NFS/SMB decided to start using it. > I think SMB has the concept of io priorities within a single stream ... > Steve? Yes - in theory SMB3 does, but I need to research this more to see if useable here. Will also discuss with others at SambaXP to see if ideas from others. Also note that SMB3 has a per-io flag (for read and write) that allows "unbuffered" and "writethrough" to be set on a per operation basis (not just on a per-file handle basis). Would be interesting if we could get hints on when to set these flags on a per-operation basis (rather than just on the handle at open time). -- Thanks, Steve -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
