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]
Date:	Wed, 13 Jan 2010 06:13:41 -0500
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Shaohua Li <shaohua.li@...el.com>
Cc:	Corrado Zoccolo <czoccolo@...il.com>,
	"jens.axboe@...cle.com" <jens.axboe@...cle.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"jmoyer@...hat.com" <jmoyer@...hat.com>,
	"guijianfeng@...fujitsu.com" <guijianfeng@...fujitsu.com>,
	"yanmin_zhang@...ux.intel.com" <yanmin_zhang@...ux.intel.com>
Subject: Re: [PATCH]cfq-iosched: don't stop async queue with async requests
	pending

On Wed, Jan 13, 2010 at 04:23:22PM +0800, Shaohua Li wrote:
> On Wed, Jan 13, 2010 at 04:18:47PM +0800, Corrado Zoccolo wrote:
> > On Wed, Jan 13, 2010 at 8:44 AM, Shaohua Li <shaohua.li@...el.com> wrote:
> > > My SSD speed of direct write is about 80m/s, while I test page writeback,
> > > the speed can only go to 68m/s. Below patch fixes this.
> > > It appears we missused cfq_should_idle in cfq_may_dispatch. cfq_should_idle
> > > means a queue should idle because it's seekless sync queue or it's the last queue,
> > > which is to maintain service tree time slice. So it doesn't mean the
> > > last queue is always a sync queue. If the last queue is asyn queue,
> > > we definitely shouldn't stop dispatch requests because of pending async
> > > requests.
> > 
> > An other option is that cfq_should_idle returns false for async
> > queues, since cfq will never idle on them.
> I'm considering this option too, but it appears we need make async queue
> idle to maintain domain time slice.

IMHO, we don't have to wait on async write service tree. Generally aysnc
write queus contain many requests and they are not like reads where next
request is expected. So idling on aysnc write service tree is waste of
time and will lead to reduced throughput.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ