From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de ([195.135.220.15]:56271 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750859AbcEHVrO (ORCPT ); Sun, 8 May 2016 17:47:14 -0400 From: NeilBrown To: Christoph Hellwig , viro@zeniv.linux.org.uk, axboe@fb.com Date: Mon, 09 May 2016 07:47:04 +1000 Cc: milosz@adfin.com, linux-fsdevel@vger.kernel.org, linux-block@vger.kernel.org, linux-api@vger.kernel.org Subject: Re: [PATCH 4/6] vfs: add the RWF_HIPRI flag for preadv2/pwritev2 In-Reply-To: <1457017443-17662-5-git-send-email-hch@lst.de> References: <1457017443-17662-1-git-send-email-hch@lst.de> <1457017443-17662-5-git-send-email-hch@lst.de> Message-ID: <874ma8usrr.fsf@notabene.neil.brown.name> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Sender: linux-fsdevel-owner@vger.kernel.org List-ID: --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable 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". >=20=20 > +/* flags for preadv2/pwritev2: */ > +#define RWF_HIPRI 0x00000001 /* high priority request, poll if possibl= e */ 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 o= f 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 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXL7PYAAoJEDnsnt1WYoG5wE8P+gOn2RRXDO0ZyV5HO5yrL0xA BnUEZvK+iCjsggVDem+lsoawdx0RxjL8XIom8MqwaNsvTQKO2qsOEq+aMgbx0gyS u+FTZu8xnJ2AHgcPq2Rvcqh8KMq4e59H7XyEJi6cMiw3fhlI0JXx1ze4ldR0Juk/ XSbDzh9Gjj/g4A7xY6caGLyBEN0kssWsqfDD2K06pLRgo+yUwoNLS9UAH+sc6Nnk oymT/f7tvwLusEbNnJEi+B0SEtbLaTiyRaiNBUpCQOQjb/Sb+XpYFIiE3jUW5wII ZSu8GKcJzQko1+DRmLsgg6yTEPTBuP4y4sNslZBM0Zw46rqHZw3XuF7v9P4pZous rPM/mSr7OeolraKIQ17jbgaxT5oCXOb1pS6lyrrRoGZWFDq/5HnOJpDIWH/dN8I3 +JdtH9WD+Bw92WTWHtJkYgIxVWgZpyNy6cUF3MKWoSIKjTxIQLDvMRBNcKpnTmbl 7iA9JvIG94tUfmSuhl+Q8NphFR+UngoFsDA6EmBwRFAmdkdynyEY26Q1v3mGfLWY 2ZkY85m+puD2lr8lz//Ni1Nn5QcCqz+cHiKCcPoLNdWCjWIKv2a73FE+ntNpF7BH bungow73ZD5LcCYEQ7GZxKTS4leVDXj7SjmFd7sr/+tZ+yG272Lt6Nz4koAAKjqG JfacBkwOQYvZn+AppQRX =xLQf -----END PGP SIGNATURE----- --=-=-=--