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]

Date:	Mon, 21 Jun 2010 14:52:41 -0400
From:	Jeff Moyer <jmoyer@...hat.com>
To:	Jens Axboe <axboe@...nel.dk>
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

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

Cheers,
Jeff
--
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/