linux-ext4 - 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: <20100408141741.GD10879@redhat.com>
Date:	Thu, 8 Apr 2010 10:17:41 -0400
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Jens Axboe <jens.axboe@...cle.com>
Cc:	Jeff Moyer <jmoyer@...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 at 04:09:44PM +0200, Jens Axboe wrote:

[..]
> 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).
> 

True. I guess this is relatively simple yield implementation where we are
telling IO scheduler that there is no more IO coming on this context so
don't waste time idling. That's a different thing that after giving up
slice, cfq might schedule in another sequential reader instead of
journalling thread.

Ideally it would be better to be also able to specify who to transfer
remaining slice to. I am not sure if there is an easy way to pass this
info CFQ.

So this implementation might be good first step.

Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html