linux-kernel - Re: [PATCH 03/24] io-controller: bfq support of in-class preemption

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: <4A6EE4A0.6080700@redhat.com>
Date:	Tue, 28 Jul 2009 13:44:32 +0200
From:	Jerome Marchand <jmarchan@...hat.com>
To:	Vivek Goyal <vgoyal@...hat.com>
CC:	linux-kernel@...r.kernel.org,
	containers@...ts.linux-foundation.org, dm-devel@...hat.com,
	jens.axboe@...cle.com, nauman@...gle.com, dpshah@...gle.com,
	ryov@...inux.co.jp, guijianfeng@...fujitsu.com,
	balbir@...ux.vnet.ibm.com, righi.andrea@...il.com,
	lizf@...fujitsu.com, mikew@...gle.com, fchecconi@...il.com,
	paolo.valente@...more.it, fernando@....ntt.co.jp,
	s-uchida@...jp.nec.com, taka@...inux.co.jp, jmoyer@...hat.com,
	dhaval@...ux.vnet.ibm.com, m-ikeda@...jp.nec.com, agk@...hat.com,
	akpm@...ux-foundation.org, peterz@...radead.org
Subject: Re: [PATCH 03/24] io-controller: bfq support of in-class preemption

Vivek Goyal wrote:
> Hi Jerome,
> 
> Thanks for testing it out. I could also reproduce the issue.
> 
> I had assumed that RT queue will always preempt non-RT queue and hence if
> there is an RT ioq/request pending, the sd->next_entity will point to
> itself and any queue which is preempting it has to be on same service
> tree.
> 
> But in your test case it looks like that RT async queue is pending and 
> there is some sync BE class IO going on. It looks like that CFQ allows
> sync queue preempting async queue irrespective of class, so in this case
> sync BE class reader will preempt async RT queue and that's where my
> assumption is broken and we see BUG_ON() hitting.
> 
> Can you please tryout following patch. It is a quick patch and requires
> more testing. It solves the crash but still does not solve the issue of
> sync queue always preempting async queues irrespective of class. In
> current scheduler we always schedule the RT queue first (whether it be
> sync or async). This problem requires little more thought.

I've tried it: I can't reproduce the issue anymore and I haven't seen any
other problem so far.
By the way, what is the expected result regarding fairness among different
groups when IO from different classes are run on each group? For instance,
if we have RT IO going on on one group, BE IO on an other and Idle IO on a
third group, what is the expected result: should the IO time been shared
fairly between the groups or should RT IO have priority? As it is now, the
time is shared fairly between BE and RT groups and the last group running
Idle IO hardly get any time.

Jerome

> 
> In this patch, we just check next entity on same class service tree and
> if one is present, stick new queue in front of it. We don't rely on
> sd->next_active, which could be pointing to a queue of different class
> in same group (scheduling_data).
>  
> ---
>  block/elevator-fq.c |   16 +++++-----------
>  1 file changed, 5 insertions(+), 11 deletions(-)
> 
> Index: linux8/block/elevator-fq.c
> ===================================================================
> --- linux8.orig/block/elevator-fq.c	2009-07-27 18:13:34.000000000 -0400
> +++ linux8/block/elevator-fq.c	2009-07-27 18:18:49.000000000 -0400
> @@ -946,21 +946,15 @@ static void __bfq_activate_entity(struct
>  	if (add_front) {
>  		struct io_entity *next_entity;
>  
> -		/* Determine the entity which will be dispatched next */
> -		next_entity = sd->next_active;
> +		/*
> +		 * Determine the entity which will be dispatched next on
> +		 * same service tree.
> +		 */
> +		next_entity = __bfq_lookup_next_entity(st);
>  
>  		if (next_entity && next_entity != entity) {
> -			struct io_service_tree *new_st;
>  			u64 delta;
>  
> -			new_st = io_entity_service_tree(next_entity);
> -
> -			/*
> -			 * At this point, both entities should belong to
> -			 * same service tree as cross service tree preemption
> -			 * is automatically taken care by algorithm
> -			 */
> -			BUG_ON(new_st != st);
>  			entity->finish = next_entity->finish - 1;
>  			delta = bfq_delta(entity->budget, entity->weight);
>  			entity->start = entity->finish - delta;

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