linux-kernel - Re: [RFC] Block IO Controller V3

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: <20091130171347.GH11670@redhat.com>
Date:	Mon, 30 Nov 2009 12:13:47 -0500
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Gui Jianfeng <guijianfeng@...fujitsu.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, jmoyer@...hat.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, czoccolo@...il.com
Subject: Re: [RFC] Block IO Controller V3

On Mon, Nov 30, 2009 at 03:29:52PM +0800, Gui Jianfeng wrote:
> Vivek Goyal wrote:
> > Hi Jens,
> > 
> > This is V3 of the Block IO controller patches on top of "for-2.6.33" branch
> > of block tree.
> > 
> ...
> 
> Hi Vivek,
> 
> If an idle task is running group A and a normal task is running in group B, these
> two group have the same weight, I think IO Controller should isolate group A and
> group B, these two group should get 50% of the IO bw for each, right? But for this case,
> we don't see any isolation, instead, group B monopolizes almost all IO BW. I guess
> the major reason is idle cfqq is only allowed to dispatch one request and get expired.
> I think in order to get better isolation, we shouldn't expire the idle cfqq immediately
> if this idle queue is the only one this its group. The following patch enable idling
> for idle queue and prevent expiring it immediately after dispatch one request if it's 
> the only one in group. This patch is working for V3, hasn't tested on V4 yet.
> 

Hi Gui,

Thanks for the patch. I have intentionally kept idle queue make dispatch
one request at a time system wide irrespective of group.

What's the use case scenario of enforcing idle dispatch more based on
group weight. If somebody has marked a queue idle, he is not expecting
much of that queue anyway.

Now one can argue that for better isolation, don't make idle class system
wide and an idle task should get more disk time if there are no other
queues with-in group.

So for the time being I will leave as it is. We can fix this once somebody
needs stronger isolation even for idle tasks.

Thanks
Vivek
 
> Signed-off-by: Gui Jianfeng <guijianfeng@...fujitsu.com>
> ---
>  block/cfq-iosched.c |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/block/cfq-iosched.c b/block/cfq-iosched.c
> index 6f9d019..3440837 100644
> --- a/block/cfq-iosched.c
> +++ b/block/cfq-iosched.c
> @@ -900,7 +900,7 @@ static bool cfq_should_idle(struct cfq_data *cfqd, struct cfq_queue *cfqq)
>  	struct cfq_rb_root *service_tree = cfqq->service_tree;
>  
>  	/* We never do for idle class queues. */
> -	if (prio == IDLE_WORKLOAD)
> +	if (prio == IDLE_WORKLOAD && cfqq->cfqg->nr_cfqq > 1)
>  		return false;
>  
>  	/* We do for queues that were marked with idle window flag. */
> @@ -2336,7 +2336,7 @@ static int cfq_dispatch_requests(struct request_queue *q, int force)
>  	 * expire an async queue immediately if it has used up its slice. idle
>  	 * queue always expire after 1 dispatch round.
>  	 */
> -	if (cfqd->busy_queues > 1 && ((!cfq_cfqq_sync(cfqq) &&
> +	if (cfqq->cfqg->nr_cfqq  > 1 && ((!cfq_cfqq_sync(cfqq) &&
>  	    cfqq->slice_dispatch >= cfq_prio_to_maxrq(cfqd, cfqq)) ||
>  	    cfq_class_idle(cfqq))) {
>  		cfqq->slice_end = jiffies + 1;
> -- 
> 1.5.4.rc3
> 
> -- 
> Regards
> Gui Jianfeng
--
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/