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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 29 Jun 2011 09:04:55 +0800 From: Shaohua Li <shaohua.li@...el.com> To: Vivek Goyal <vgoyal@...hat.com> Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "jaxboe@...ionio.com" <jaxboe@...ionio.com>, "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>, "linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>, "khlebnikov@...nvz.org" <khlebnikov@...nvz.org>, "jmoyer@...hat.com" <jmoyer@...hat.com> 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. Thanks, Shaohua -- 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