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  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, 29 Jun 2011 09:04:55 +0800
From:	Shaohua Li <>
To:	Vivek Goyal <>
Cc:	"" <>,
	"" <>,
	"" <>,
	"" <>,
	"" <>,
	"" <>
Subject: Re: [RFC PATCH 0/3] block: Fix fsync slowness with CFQ cgroups

On Tue, 2011-06-28 at 21:04 +0800, Vivek Goyal wrote:
> On Tue, Jun 28, 2011 at 10:03:54AM +0800, Shaohua Li wrote:
> [..]
> > > > > Any feedback on how to solve this issue is appreciated.
> > > > Hi Vivek,
> > > > can we introduce a group think time check in cfq? say in a group the
> > > > last queue is backed for the group and the queue is a non-idle queue, if
> > > > the group think time is big, we don't allow the group idle and preempt
> > > > could happen. The fsync thread is a non-idle queue with Corrado's patch,
> > > > this allows fast group switch.
> > > 
> > > In this case regular queue idle is hitting and not group idle. So some
> > > kind of think time stats probably might be useful for group idle check
> > > but not necessarily for queue idle.
> > I thought your problem is group idle issue. fsync uses WRITE_SYNC, which
> > will make the queue be sync-non-idle because REQ_NOIDLE is set. This is
> > exactly what Corrado's patch for. a fsync queue itself isn't idle unless
> > it's the last queue in a group. Am I missing anything?
> We idle on last queue on sync-noidle tree. So we idle on fysnc queue as
> it is last queue on sync-noidle tree. That's how we provide protection
> to all sync-noidle queues against sync-idle queues. Instead of idling
> on individual quues we do idling in group and that is on service tree.
Ok. but this looks silly. We are idling in a noidle service tree or a
group (backed by the last queue of the tree or group) because we assume
the tree or group can dispatch a request soon. But if the think time of
the tree or group is big, the assumption isn't true. Doing idle here is
blind. I thought we can extend the think time check for both service
tree and group.


To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists