linux-kernel - Re: [PATCH 07/10] fs: make generic file read/write functions plug

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 4 Mar 2011 14:40:09 +0100
From:	Jens Axboe <jaxboe@...ionio.com>
To:	"hch@...radead.org" <hch@...radead.org>
CC:	Vivek Goyal <vgoyal@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 07/10] fs: make generic file read/write functions plug

On 2011-03-04 14:25, hch@...radead.org wrote:
> On Fri, Mar 04, 2011 at 02:22:21PM +0100, Jens Axboe wrote:
>> Good catch, we need to modify that logic. If the task is currently
>> plugged, it should not dispatch until blk_finish_plug() is called.
>> Essentially SYNC will not control dispatch. Will allow us to clean up
>> that logic, too.
> 
> <broken-record-mode>
> 
> Time to use the opportunity to sort out what the various bio/request
> flags mean.
> 
> REQ_UNPLUG should simply go away with the explicit stack plugging.
> What's left for REQ_SYNC?  It'll control if the request goes into the
> sync bucket and some cfq tweaks.  We should clearly document what it
> does.

Yes, REQ_UNPLUG goes away, it has no meaning anymore since the plugging
is explicitly done by the caller.

With REQ_SYNC, lets make the sync/async thing apply to both reads and
writes. Right now reads are inherently sync, writes are sometimes
(O_DIRECT). So lets stop making it more murky by mixing up READ and
SYNC.

> REQ_META?  Maybe we should finally agree what it does and decide if it
> should be used consistenly.  Especially the priority over REQ_SYNC in
> cfq still looks somewhat odd, as does the totally inconsequent use.

For me it was primarily a blktrace hint, but yes it does have prio boost
properties in CFQ as well. I'm inclined to let those stay the way they
are. Not sure we can properly call it anything outside of a hint that
these IO have slightly higher priority, at least I would not want to
lock the IO scheduler into to something more concrete than that.

-- 
Jens Axboe

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/