All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.