All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@redhat.com>
To: Chad Talbott <ctalbott@google.com>
Cc: jaxboe@fusionio.com, guijianfeng@cn.fujitsu.com,
	mrubin@google.com, teravest@google.com, jmoyer@redhat.com,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Avoid preferential treatment of groups that aren't backlogged
Date: Fri, 11 Feb 2011 13:30:25 -0500	[thread overview]
Message-ID: <20110211183024.GH8773@redhat.com> (raw)
In-Reply-To: <AANLkTimO+CG_iCHZ+9D1EtrZp+z0k0+xUN_WMsqU3NNk@mail.gmail.com>

On Thu, Feb 10, 2011 at 11:06:37AM -0800, Chad Talbott wrote:
> On Wed, Feb 9, 2011 at 8:02 PM, Vivek Goyal <vgoyal@redhat.com> wrote:
> > - What happens when cfqd->active_generation wraps over? Should we use
> >  functions which take care of wrapping.
> 
> To be absolutely correct, you're right.  But even if the service tree
> becomes completely idle every microsecond, we still have 1/2 million
> years before the first wrap.

Ok, so I guess it fine for time being untile and unless we encounter a
really fast device. 

> 
> > - So when generation number changes you want to put the newly backlogged
> >  group at the front of tree and not at the end of it? Though it kind
> >  of make sense as any continuously backlogged groups will be on service
> >  tree for long time and newly backlogged groups are either new IO
> >  starting or some application which high think time and which does IO
> >  one in a while and does not keep disk occupied for very long time. In
> >  such cases it probably is not a bad idea to put newly backlogged
> >  groups at the beginning of the tree.
> 
> Yes, that's it exactly.
> 
> >> @@ -906,6 +905,9 @@ cfq_group_service_tree_del(struct cfq_data *cfqd, struct cfq_group *cfqg)
> >>       if (!RB_EMPTY_NODE(&cfqg->rb_node))
> >>               cfq_rb_erase(&cfqg->rb_node, st);
> >>       cfqg->saved_workload_slice = 0;
> >> +     cfqg->generation_num = cfqd->active_generation;
> >> +     if (RB_EMPTY_ROOT(&st->rb))
> >> +             cfqd->active_generation++;
> >
> > I don't understand that what is the significance behind chaning generation
> > number when tree is idle? When tree is idle does not mean that few
> > recently deleted groups will not get backlogged soon?
> 
> It's a result of being both fair and work conserving.  If *all* the
> queues are without requests, then whoever next has requests should get
> to use the disk fully to be work-conserving.  But if the disk is
> always kept busy (by anyone), then there is competition and we have to
> provide fairness.

Well, service tree being idle does not mean that nobody else is using
disk. We could have the case where service tree is idle in between while
all the readers are in their think time phase. In that case I think one
could further refine the logic where change the generation only if tree is
idle for more than slice_idle time.

But I think we can do that later if we run into some issues. For the
time being I am fine with it as it has been working for you guys.

Can you please update the patch to correct the commit description and
repost. 

Thanks
Vivek

      reply	other threads:[~2011-02-11 18:30 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-10  1:32 [PATCH] Avoid preferential treatment of groups that aren't backlogged Chad Talbott
2011-02-10  2:09 ` Vivek Goyal
2011-02-10  2:45   ` Chad Talbott
2011-02-10  3:57     ` Vivek Goyal
2011-02-10 18:57       ` Chad Talbott
2011-02-11  0:36         ` Chad Talbott
2011-02-11 18:15           ` Vivek Goyal
2011-02-18 19:54             ` Vivek Goyal
2011-02-10  4:02 ` Vivek Goyal
2011-02-10 19:06   ` Chad Talbott
2011-02-11 18:30     ` Vivek Goyal [this message]

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=20110211183024.GH8773@redhat.com \
    --to=vgoyal@redhat.com \
    --cc=ctalbott@google.com \
    --cc=guijianfeng@cn.fujitsu.com \
    --cc=jaxboe@fusionio.com \
    --cc=jmoyer@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mrubin@google.com \
    --cc=teravest@google.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.