Re: trying to understand READ_META, READ_SYNC, WRITE_SYNC & co

[Jeff Moyer]

Jens Axboe <axboe@xxxxxxxxx> writes:

> On 21/06/10 20.52, Jeff Moyer wrote:
>> Jens Axboe <axboe@xxxxxxxxx> 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.

Oh, I'm not arguing for that approach.  I just wanted to make it clear
that it can and does have a noticible impact.

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