linux-kernel - Re: trying to understand READ_META, READ_SYNC, WRITE

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]

Message-ID: <4C1FB66B.1030203@kernel.dk>
Date:	Mon, 21 Jun 2010 20:58:51 +0200
From:	Jens Axboe <axboe@...nel.dk>
To:	Jeff Moyer <jmoyer@...hat.com>
CC:	Christoph Hellwig <hch@....de>, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: trying to understand READ_META, READ_SYNC, WRITE_SYNC & co

On 21/06/10 20.52, Jeff Moyer wrote:
> Jens Axboe <axboe@...nel.dk> writes:
> 
>> On 2010-06-21 11:48, Christoph Hellwig wrote:
>>> Now how do we use these flags in the block layer?
>>>  
>>>  - REQ_META
>>>
>>> 	The only place where we ever use this flag is inside the
>>> 	cfq scheduler. In cfq_choose_req we use it to give a meta
>>> 	request priority over one that doesn't have it.  But before
>>> 	that we already do the same preference check with rw_is_sync,
>>> 	which evaluates to true for requests with that are either
>>> 	reads or have REQ_SYNC set.  So for reads the REQ_META flag
>>> 	here effectively is a no-op, and for writes it gives less
>>> 	priority than REQ_SYNC.
>>> 	In addition to that we use it to account for pending metadata
>>> 	requests in cfq_rq_enqueued/cfq_remove_request which gets
>>> 	checked in cfq_should_preempt to give priority to a meta
>>> 	request if the other queue doesn't have any pending meta
>>> 	requests.  But again this priority comes after a similar
>>> 	check for sync requests that checks if the other queue has
>>> 	been marked to have sync requests pending.
>>
>> It's also annotation for blktrace, so you can tell which parts of the IO
>> is meta data etc. The scheduler impact is questionable, I doubt it makes
>> a whole lot of difference.
> 
> Really?  Even after I showed the performance impact of setting that bit
> for journal I/O?
> 
> http://lkml.org/lkml/2010/4/1/344

It's definitely a win in some cases, as you showed there as well.
My initial testing a long time ago had some nice benefits too. So
perhaps the above wasn't worded very well, I always worry that we
have regressions doing boosts for things like that. But given that
meta data is something that needs to be done before we get to the
real data, bumping priority generally seems like a good thing to do.

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