From: Vivek Goyal <vgoyal@redhat.com>
To: Corrado Zoccolo <czoccolo@gmail.com>
Cc: Jeff Moyer <jmoyer@redhat.com>,
Linux-Kernel <linux-kernel@vger.kernel.org>,
Jens Axboe <jens.axboe@oracle.com>
Subject: Re: [PATCH 4/4] cfq-iosched: fix corner cases in idling logic
Date: Wed, 2 Dec 2009 09:38:08 -0500 [thread overview]
Message-ID: <20091202143808.GB31715@redhat.com> (raw)
In-Reply-To: <4e5e476b0912020614r7352727an62f441e191ae6609@mail.gmail.com>
On Wed, Dec 02, 2009 at 03:14:22PM +0100, Corrado Zoccolo wrote:
> Hi Jeff,
> On Wed, Dec 2, 2009 at 2:42 PM, Jeff Moyer <jmoyer@redhat.com> wrote:
> > Corrado Zoccolo <czoccolo@gmail.com> writes:
> >
> >> Idling logic was disabled in some corner cases, leading to unfair share
> >> for noidle queues.
> >> * the idle timer was not armed if there were other requests in the
> >> driver. unfortunately, those requests could come from other workloads,
> >> or queues for which we don't enable idling. So we will check only
> >> pending requests from the active queue
> >> * rq_noidle check on no-idle queue could disable the end of tree idle if
> >> the last completed request was rq_noidle. Now, we will disable that
> >> idle only if all the queues served in the no-idle tree had rq_noidle
> >> requests.
> >>
> >> Reported-by: Vivek Goyal <vgoyal@redhat.com>
> >> Signed-off-by: Corrado Zoccolo <czoccolo@gmail.com>
> >
> >> @@ -2606,17 +2608,27 @@ static void cfq_completed_request(struct request_queue *q, struct request *rq)
> >> cfq_clear_cfqq_slice_new(cfqq);
> >> }
> >> /*
> >> - * If there are no requests waiting in this queue, and
> >> - * there are other queues ready to issue requests, AND
> >> - * those other queues are issuing requests within our
> >> - * mean seek distance, give them a chance to run instead
> >> - * of idling.
> >> + * Idling is not enabled on:
> >> + * - expired queues
> >> + * - idle-priority queues
> >> + * - async queues
> >> + * - queues with still some requests queued
> >> + * - when there is a close cooperator
> >> */
> >
> > I'm not sure this logic is correct. Is this for the 2.6.33 branch?
> Yes.
> > If so, the coop flag now means that multiple processes share the same
> > cfqq. Are you sure this is the right thing to do for close cooperators?
> I'm not sure. I didn't change the logic for close cooperators:
> - else if (cfqq_empty && !cfq_close_cooperator(cfqd, cfqq) &&
> - sync && !rq_noidle(rq))
> - cfq_arm_slice_timer(cfqd);
> + else if (sync && cfqq_empty &&
> + !cfq_close_cooperator(cfqd, cfqq)) {
> + cfqd->noidle_tree_requires_idle |= !rq_noidle(rq);
>
> I changed the rq_noidle part, and rewrote the comment to be aligned
> with the code.
> So I don't mind if you improve (or just remove) the close cooperator part.
> Probably, you should do a test where close cooperating processes are competing
> with a sequential reader, to see the effect of idling or not on them.
>
I also can't find what's wrong with this. Previously we were not merging
close cooperators in a single queue. So if we found a close cooperator
we chose to not idle and move to that close cooperator. Now we try to
merge all the close cooperators in a single queue. But that merging has
not taken place yet and will happen when next request comes.
A normal sequential reader will not find the close cooperator. Only the
queues which should be merged will find the close cooperator. If anyway
these queues are going to be merged soon, there is proably no point in
continuing to idle on this queue in case we found a close cooperator.
So, to me even in new code by jeff, it probably is fine to continue with
policy of not idling if we found a close cooperator.
Thanks
Vivek
> Thanks
> Corrado
>
> >
> > Cheers,
> > Jeff
>
> --
> __________________________________________________________________________
>
> dott. Corrado Zoccolo mailto:czoccolo@gmail.com
> PhD - Department of Computer Science - University of Pisa, Italy
> --------------------------------------------------------------------------
> The self-confidence of a warrior is not the self-confidence of the average
> man. The average man seeks certainty in the eyes of the onlooker and calls
> that self-confidence. The warrior seeks impeccability in his own eyes and
> calls that humbleness.
> Tales of Power - C. Castaneda
next prev parent reply other threads:[~2009-12-02 14:38 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-24 13:49 [PATCH 4/4] cfq-iosched: fix corner cases in idling logic Corrado Zoccolo
2009-11-24 14:42 ` Vivek Goyal
2009-12-02 13:42 ` Jeff Moyer
2009-12-02 14:14 ` Corrado Zoccolo
2009-12-02 14:38 ` Vivek Goyal [this message]
2009-12-02 14:47 ` Jeff Moyer
2009-12-02 15:02 ` Vivek Goyal
2009-12-02 15:13 ` Jeff Moyer
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=20091202143808.GB31715@redhat.com \
--to=vgoyal@redhat.com \
--cc=czoccolo@gmail.com \
--cc=jens.axboe@oracle.com \
--cc=jmoyer@redhat.com \
--cc=linux-kernel@vger.kernel.org \
/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