linux-kernel - Re: [PATCH 18/20] blkio: arm idle timer even if think time is great then time slice left

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: <20091104191709.GJ2870@redhat.com>
Date:	Wed, 4 Nov 2009 14:17:09 -0500
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Jeff Moyer <jmoyer@...hat.com>
Cc:	linux-kernel@...r.kernel.org, jens.axboe@...cle.com,
	nauman@...gle.com, dpshah@...gle.com, lizf@...fujitsu.com,
	ryov@...inux.co.jp, fernando@....ntt.co.jp, s-uchida@...jp.nec.com,
	taka@...inux.co.jp, guijianfeng@...fujitsu.com,
	balbir@...ux.vnet.ibm.com, righi.andrea@...il.com,
	m-ikeda@...jp.nec.com, akpm@...ux-foundation.org, riel@...hat.com,
	kamezawa.hiroyu@...fujitsu.com
Subject: Re: [PATCH 18/20] blkio: arm idle timer even if think time is
	great then time slice left

On Wed, Nov 04, 2009 at 02:04:45PM -0500, Jeff Moyer wrote:
> Vivek Goyal <vgoyal@...hat.com> writes:
> 
> > o Now we plan to wait for a queue to get backlogged before we expire it. So
> >   we need to arm slice timer even if think time is greater than slice left.
> >   if process sends next IO early and time slice is left, we will dispatch it
> >   otherwise we will expire the queue and move on to next queue.
> 
> Should this be rolled into patch 17?  I'm just worried about breaking
> bisection runs.  What happens if this patch isn't applied?
> 

We don't wait for queue to get busy and expire it. That means we will not
get fairness numbers between groups even in simple case of sequential
readers.

So nothing catastrophic. Bisection will not be broken as such (kernel
compiles and boots).

In fact thinking more about it, I might have broken close cooperator logic
as I am waiting for queue to get busy irrespective of the fact whether
there is a close cooperating queue or not. I think need to check for
cooperating queue in cfqq_should_wait_busy() and if one is available,
don't busy wait. This should still maintain fairness at group level as
cooperating queues are not selected across groups and if one cooperating
queue is available in same group, that means expiry of this current queue
will not delete group from service tree and group will still get fair
share. 

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