[4/6] vfs: add the RWF_HIPRI flag for preadv2/pwritev2
diff mbox

Message ID 1457017443-17662-5-git-send-email-hch@lst.de
State New
Headers show

Commit Message

Christoph Hellwig March 3, 2016, 3:04 p.m. UTC
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.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Stephen Bates <stephen.bates@pmcs.com>
Tested-by: Stephen Bates <stephen.bates@pmcs.com>
Acked-by: Jeff Moyer <jmoyer@redhat.com>
---
 fs/read_write.c         | 6 ++++--
 include/linux/fs.h      | 1 +
 include/uapi/linux/fs.h | 3 +++
 3 files changed, 8 insertions(+), 2 deletions(-)

Comments

NeilBrown May 8, 2016, 9:47 p.m. UTC | #1
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
Christoph Hellwig May 11, 2016, 8:55 a.m. UTC | #2
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

Patch
diff mbox

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 */