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: <x49ljcy9g4t.fsf@segfault.boston.devel.redhat.com>
Date:	Thu, 08 Apr 2010 10:24:18 -0400
From:	Jeff Moyer <jmoyer@...hat.com>
To:	Jens Axboe <jens.axboe@...cle.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

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.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ