lkml.org 
[lkml]   [2010]   [Jun]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: trying to understand READ_META, READ_SYNC, WRITE_SYNC & co
On Mon, Jun 21, 2010 at 09:16:33PM +0200, Jens Axboe wrote:
> Yes, but that's a separate thing. The point is that boosting meta data
> IO is done by others as well. That we don't fully do the same on the
> hw side is a different story. That doesn't mean that the io scheduler
> boost isn't useful.

Well, the FUA bit is useful for writes. And I agree that we need to
prioritize log I/O metadata. On the other hand at least for XFS most
other metadata writes actually are asynchronous - there's no need to
prioritize those.

> > We use the explicit unplugging, yes - but READ_META also includes
> > REQ_SYNC which is not used anywhere.
>
> That does look superfluous.

The above should READ_SYNC, but the same still applies.

> > We've only started using any kind of sync tag last year in ->writepage in
> > commit a64c8610bd3b753c6aff58f51c04cdf0ae478c18 "block_write_full_page:
> > Use synchronous writes for WBC_SYNC_ALL writebacks", switching from
> > WRITE_SYNC to WRITE_SYNC_PLUG a bit later in commit
> > 6e34eeddf7deec1444bbddab533f03f520d8458c "block_write_full_page: switch
> > synchronous writes to use WRITE_SYNC_PLUG"
> >
> > Before that we used plain WRITE, which had the normal idling logic.
>
> Plain write does not idle.

Well, whatever logic we use for normal files. Note that all the commits
above were introduced in 2.6.29. That's where the horrible fsync
latency regressions due to the idling logic that Jeff is fighting were
introduced. So there's defintively something wrong going on here.



\
 
 \ /
  Last update: 2010-06-21 21:23    [W:1.753 / U:1.176 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site