| Message ID | 1457017443-17662-5-git-send-email-hch@lst.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Fri, Mar 04 2016, Christoph Hellwig wrote: > This adds a flag that tells the file system that this is a high priority > request for which it's worth to poll the hardware. The flag is purely > advisory and can be ignored if not supported. Here you say the flag is "advice". > > +/* flags for preadv2/pwritev2: */ > +#define RWF_HIPRI 0x00000001 /* high priority request, poll if possible */ This text makes it sound like a firm "request" ("if possible"). In the man page posted separately it says: +.BR RWF_HIPRI " (since Linux 4.6)" +High priority read/write. Allows block based filesystems to use polling of the +device, which provides lower latency, but may use additional ressources. (Currently +only usable on a file descriptor opened using the +.BR O_DIRECT " flag)." So now it "allows", which is different again. The differences may be subtle, but consistency is nice. Also in that man page fragment: > provides lower latency, but may use additional ressources Is this a "latency vs throughput" trade-off, or something more subtle? It would be nice to make the decision process as obvious as possible for the developer considering the use of this flag. (and s/ressources/resources/) NeilBrown
On Mon, May 09, 2016 at 07:47:04AM +1000, NeilBrown wrote: > On Fri, Mar 04 2016, Christoph Hellwig wrote: > > > This adds a flag that tells the file system that this is a high priority > > request for which it's worth to poll the hardware. The flag is purely > > advisory and can be ignored if not supported. > > Here you say the flag is "advice". > > > > > +/* flags for preadv2/pwritev2: */ > > +#define RWF_HIPRI 0x00000001 /* high priority request, poll if possible */ > > This text makes it sound like a firm "request" ("if possible"). "request" here is in the sense of an I/O request. Better wording highly welcome. > > > provides lower latency, but may use additional ressources > > Is this a "latency vs throughput" trade-off, or something more subtle? > It would be nice to make the decision process as obvious as possible for > the developer considering the use of this flag. If you poll you can't do anything else, so you end up using CPU cycles to wait which otherwise could do something productive. -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/fs/read_write.c b/fs/read_write.c index 799d25f..cf377cf 100644 --- a/fs/read_write.c +++ b/fs/read_write.c @@ -698,10 +698,12 @@ static ssize_t do_iter_readv_writev(struct file *filp, struct iov_iter *iter, struct kiocb kiocb; ssize_t ret; - if (flags) + if (flags & ~RWF_HIPRI) return -EOPNOTSUPP; init_sync_kiocb(&kiocb, filp); + if (flags & RWF_HIPRI) + kiocb.ki_flags |= IOCB_HIPRI; kiocb.ki_pos = *ppos; ret = fn(&kiocb, iter); @@ -716,7 +718,7 @@ static ssize_t do_loop_readv_writev(struct file *filp, struct iov_iter *iter, { ssize_t ret = 0; - if (flags) + if (flags & ~RWF_HIPRI) return -EOPNOTSUPP; while (iov_iter_count(iter)) { diff --git a/include/linux/fs.h b/include/linux/fs.h index 875277a..a1f731c 100644 --- a/include/linux/fs.h +++ b/include/linux/fs.h @@ -320,6 +320,7 @@ struct writeback_control; #define IOCB_EVENTFD (1 << 0) #define IOCB_APPEND (1 << 1) #define IOCB_DIRECT (1 << 2) +#define IOCB_HIPRI (1 << 3) struct kiocb { struct file *ki_filp; diff --git a/include/uapi/linux/fs.h b/include/uapi/linux/fs.h index 149bec8..d246339 100644 --- a/include/uapi/linux/fs.h +++ b/include/uapi/linux/fs.h @@ -304,4 +304,7 @@ struct fsxattr { #define SYNC_FILE_RANGE_WRITE 2 #define SYNC_FILE_RANGE_WAIT_AFTER 4 +/* flags for preadv2/pwritev2: */ +#define RWF_HIPRI 0x00000001 /* high priority request, poll if possible */ + #endif /* _UAPI_LINUX_FS_H */