public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Gui Jianfeng <guijianfeng@cn.fujitsu.com>
To: Corrado Zoccolo <czoccolo@gmail.com>
Cc: Vivek Goyal <vgoyal@redhat.com>,
	Jens Axboe <jens.axboe@oracle.com>,
	linux kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] cfq: Take whether cfq group is changed into account when choosing service tree
Date: Tue, 15 Dec 2009 09:06:37 +0800	[thread overview]
Message-ID: <4B26E11D.1000801@cn.fujitsu.com> (raw)
In-Reply-To: <4e5e476b0912140301x398ac2b7k5ab7fc5698b9675e@mail.gmail.com>

Corrado Zoccolo wrote:
> Hi Gui,
> On Mon, Dec 14, 2009 at 10:54 AM, Gui Jianfeng
> <guijianfeng@cn.fujitsu.com> wrote:
>> Corrado Zoccolo wrote:
>>> Hi,
>> Currently, IIUC, only the workload that didn't use up its slice will be saved, and only
>> such workloads are restoring when a group is resumed. So sometimes, we'll still get the
>> previous serving_type and workload_expires. Am i missing something?
> You are right. cfq_choose_cfqg should set the workload as expired if
> !cfqg->saved_workload_slice (just set cfqd->workload_expires = jiffies
> - 1), so the workload will be chosen again as the lowest keyed one.
> Can you send a patch to fix this?

Will do.

Thanks
Gui

>>
>>> I have one more concern, though.
>>> RT priority has now changed meaning. Before, an RT task would always
>>> have priority access to the disk. Now, a BE task in a different group,
>>> with lower weight, can steal the disk from the RT task.
>>> A way to preserve the old meaning is to consider wheter a group has RT
>>> tasks inside when sorting groups tree, and putting those groups at the
>>> front.
>>> Usually, RT tasks will be put in the root group, and this (if
>>> group_isolation=0) will automatically make sure that also the noidle
>>> workload gets serviced quickly after RT tasks release the disk. We
>>> could even enforce that, with group_isolation=0, all RT tasks are put
>>> in the root group.
>>>
>>> The rationale behind this suggestion is that groups are for user
>>> processes, while RT is system wide, since it is only root that can
>>> grant it.
>>  I agree, and one more thing, currently we can't see fairness between different
>>  idle tasks in different groups. Because we only allow idle cfqq dispatch one request
>>  for its dispatch round even if it's the only task in the cgroup, group always loose it
>>  share. So whether we can rely on group_isolation, when group_isolation == 1 we provide
>>  isolation for idle tasks.
> Agreed.
> 
> Thanks,
> Corrado
> 
>> Thanks
>> Gui
>>
>>
>>
> 
> 
> 

-- 
Regards
Gui Jianfeng


  parent reply	other threads:[~2009-12-15  1:11 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-11  5:02 [PATCH] cfq: Take whether cfq group is changed into account when choosing service tree Gui Jianfeng
2009-12-11 15:07 ` Vivek Goyal
2009-12-11 18:01   ` Corrado Zoccolo
2009-12-11 18:46     ` Vivek Goyal
2009-12-14  2:37       ` Gui Jianfeng
2009-12-14  8:39         ` Corrado Zoccolo
2009-12-14  9:54           ` Gui Jianfeng
2009-12-14 11:01             ` Corrado Zoccolo
2009-12-15  0:52               ` Vivek Goyal
2009-12-15  1:06               ` Gui Jianfeng [this message]
2009-12-15 15:23           ` Vivek Goyal
2009-12-15 16:04             ` Corrado Zoccolo
2009-12-15 16:22               ` Vivek Goyal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B26E11D.1000801@cn.fujitsu.com \
    --to=guijianfeng@cn.fujitsu.com \
    --cc=czoccolo@gmail.com \
    --cc=jens.axboe@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vgoyal@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox