Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757851AbZFZMqY (ORCPT ); Fri, 26 Jun 2009 08:46:24 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753491AbZFZMqQ (ORCPT ); Fri, 26 Jun 2009 08:46:16 -0400 Received: from mx2.redhat.com ([66.187.237.31]:52013 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751983AbZFZMqP (ORCPT ); Fri, 26 Jun 2009 08:46:15 -0400 Date: Fri, 26 Jun 2009 08:39:19 -0400 From: Vivek Goyal To: Gui Jianfeng Cc: linux-kernel@vger.kernel.org, containers@lists.linux-foundation.org, dm-devel@redhat.com, jens.axboe@oracle.com, nauman@google.com, dpshah@google.com, lizf@cn.fujitsu.com, mikew@google.com, fchecconi@gmail.com, paolo.valente@unimore.it, ryov@valinux.co.jp, fernando@oss.ntt.co.jp, s-uchida@ap.jp.nec.com, taka@valinux.co.jp, jmoyer@redhat.com, dhaval@linux.vnet.ibm.com, balbir@linux.vnet.ibm.com, righi.andrea@gmail.com, m-ikeda@ds.jp.nec.com, jbaron@redhat.com, agk@redhat.com, snitzer@redhat.com, akpm@linux-foundation.org, peterz@infradead.org Subject: Re: [PATCH 2/2] io-controller: make rt preemption happen in the whole hierarchy Message-ID: <20090626123919.GA9785@redhat.com> References: <1245443858-8487-1-git-send-email-vgoyal@redhat.com> <1245443858-8487-21-git-send-email-vgoyal@redhat.com> <4A3F3648.7080007@cn.fujitsu.com> <20090622172123.GE15600@redhat.com> <4A4079B8.4020402@cn.fujitsu.com> <20090623140250.GA4262@redhat.com> <4A41EFE1.5050101@cn.fujitsu.com> <4A44833F.8040308@cn.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A44833F.8040308@cn.fujitsu.com> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2448 Lines: 77 On Fri, Jun 26, 2009 at 04:13:51PM +0800, Gui Jianfeng wrote: > let rt queue preempt non-rt queue if needed. > Make sure comparision happens at the same level. > > Signed-off-by: Gui Jianfeng > --- > block/elevator-fq.c | 28 +++++++++++++++++++++++++++- > 1 files changed, 27 insertions(+), 1 deletions(-) > > diff --git a/block/elevator-fq.c b/block/elevator-fq.c > index 1d4ec1f..21d38f5 100644 > --- a/block/elevator-fq.c > +++ b/block/elevator-fq.c > @@ -3742,6 +3742,31 @@ int elv_iosched_expire_ioq(struct request_queue *q, int slice_expired, > return ret; > } > > +static int check_rt_preemption(struct io_queue *ioq) > +{ > + struct hlist_node *node; > + struct hlist_head *hhead = &ioq->efqd->rt_ioq_list; > + struct io_queue *rt_ioq; > + struct io_entity *entity = &ioq->entity; > + struct io_entity *new_entity; > + > + rcu_read_lock(); > + hlist_for_each_entry_rcu(rt_ioq, node, hhead, rt_node) { > + new_entity = &rt_ioq->entity; > + > + bfq_find_matching_entity(&entity, &new_entity); > + > + if (new_entity->ioprio_class == IOPRIO_CLASS_RT && > + entity->ioprio_class != IOPRIO_CLASS_RT) { > + rcu_read_unlock(); > + return 1; > + } > + } > + rcu_read_unlock(); > + > + return 0; > +} > + > /* Common layer function to select the next queue to dispatch from */ > void *elv_fq_select_ioq(struct request_queue *q, int force) > { > @@ -3823,7 +3848,8 @@ void *elv_fq_select_ioq(struct request_queue *q, int force) > */ > iog = ioq_to_io_group(ioq); > > - if (!elv_ioq_class_rt(ioq) && iog->busy_rt_queues) { > + if (!elv_ioq_class_rt(ioq) && > + (iog->busy_rt_queues || check_rt_preemption(ioq))) { > /* Hi Gui, I am not able to understand why do we need above changes? BFQ scheduler already takes care of selecting an RT queue for dispatch (if the queue is entitled to). In case a new RT queue backlogged while a BE queue is being served, we do preemtion check to make sure RT queue gets to run as soon as possible. In fact I think that busy_rt_queues infrastructure is also redundant and I plan to get rid of it. Can you please help me understand what use case are you addressing with above patch? Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/