linux-kernel - Re: [patch,rfc v2] ext3/4: enhance fsync performance when using cfq

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: <20100408192336.GV10103@kernel.dk>
Date:	Thu, 8 Apr 2010 21:23:36 +0200
From:	Jens Axboe <jens.axboe@...cle.com>
To:	Jeff Moyer <jmoyer@...hat.com>
Cc:	Vivek Goyal <vgoyal@...hat.com>, Theodore Ts'o <tytso@....edu>,
	linux-ext4@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [patch,rfc v2] ext3/4: enhance fsync performance when using cfq

On Thu, Apr 08 2010, Jeff Moyer wrote:
> Jens Axboe <jens.axboe@...cle.com> writes:
> 
> > Precisely. The next question would be how to control the yielding. In
> > this particular case, you want to be yielding to a specific cfqq. IOW,
> > you essentially want to pass your slide on to that queue. The way the
> > above is implemented, you could easily just switch to another unrelated
> > queue. And if that is done, fairness is skewed without helping the
> > yielding process at all (which was the intention).
> 
> Well, that's true in part.  Prior to this patch, the process would idle,
> keeping all other cfq_queues on the system from making progress.  With
> this patch, at least *somebody* else makes progress, getting you closer
> to running the journal thread that you're blocked on.  Ideally, you'd
> want the thread you're waiting on to get disk time next, sure.  You
> would have to pass the process information down to the I/O scheduler for
> that, and I'm not sure that the file system code knows which process to
> hand off to.  Does it?
> 
> Do we really want to go down this road at all?  I'm not convinced.

Don't get me wrong, neither am I. I'm just thinking out loud and
pondering. As a general mechanism, yield to a specific cfqq is going to
be tricky and doing a generic yield to signal that _someone_ else must
make progress before we can is better than nothing.

Continuing that train of thought, I don't think we'll ever need full
'yield to X' functionality where 'X' is a really specific target. But
for this fsync case, we know at least what we are yielding to and it
seems like a shame to throw away that information. So you could include
a hint of what to yield to, which cfq could factor in.

Dunno, I need to think a bit about the cleanliness of such an approach.
We can definitely use your patch as a starting point.

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