[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJmaN=m4sPCUjS1oy3yOavjN2wcwhMWvZE9sVehySuhibTmABQ@mail.gmail.com>
Date: Thu, 23 Apr 2020 13:13:45 -0700
From: Jesse Barnes <jsbarnes@...gle.com>
To: Doug Anderson <dianders@...omium.org>
Cc: Salman Qazi <sqazi@...gle.com>, Jens Axboe <axboe@...nel.dk>,
Bart Van Assche <bvanassche@....org>,
Ming Lei <ming.lei@...hat.com>,
linux-block <linux-block@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Gwendal Grignou <gwendal@...gle.com>,
Hannes Reinecke <hare@...e.com>, Christoph Hellwig <hch@....de>
Subject: Re: [PATCH] block: Limit number of items taken from the I/O scheduler
in one go
Jens, Bart, Ming, any update here? Or is this already applied (I didn't check)?
Thanks,
Jesse
On Mon, Apr 20, 2020 at 9:43 AM Doug Anderson <dianders@...omium.org> wrote:
>
> Hi,
>
> On Fri, Feb 7, 2020 at 12:38 PM Salman Qazi <sqazi@...gle.com> wrote:
> >
> > On Fri, Feb 7, 2020 at 12:19 PM Bart Van Assche <bvanassche@....org> wrote:
> > >
> > > On 2/7/20 10:45 AM, Salman Qazi wrote:
> > > > If I were to write this as a for-loop, it will look like this:
> > > >
> > > > for (i = 0; i == 0 || (run_again && i < 2); i++) {
> > > > /* another level of 8 character wide indentation */
> > > > run_again = false;
> > > > /* a bunch of code that possibly sets run_again to true
> > > > }
> > > >
> > > > if (run_again)
> > > > blk_mq_run_hw_queue(hctx, true);
> > >
> > > That's not what I meant. What I meant is a loop that iterates at most
> > > two times and also to break out of the loop if run_again == false.
> > >
> >
> > I picked the most compact variant to demonstrate the problem. Adding
> > breaks isn't
> > really helping the readability.
> >
> > for (i = 0; i < 2; i++) {
> > run_again = false;
> > /* bunch of code that possibly sets it to true */
> > ...
> > if (!run_again)
> > break;
> > }
> > if (run_again)
> > blk_mq_run_hw_queue(hctx, true);
> >
> > When I read this, I initially assume that the loop in general runs
> > twice and that this is the common case. It has the
> > same problem with conveying intent. Perhaps, more importantly, the
> > point of using programming constructs is to shorten and simplify the
> > code.
> > There are still two if-statements in addition to the loop. We haven't
> > gained much by introducing the loop.
> >
> > > BTW, I share your concern about the additional indentation by eight
> > > positions. How about avoiding deeper indentation by introducing a new
> > > function?
> >
> > If there was a benefit to introducing the loop, this would be a good
> > call. But the way I see it, the introduction of another
> > function is yet another way in which the introduction of the loop
> > makes the code less readable.
> >
> > This is not a hill I want to die on. If the maintainer agrees with
> > you on this point, I will use a loop.
>
> I haven't done a massive amount of analysis of this patch, but since I
> noticed it while debugging my own block series I've been keeping track
> of it. Is there any status update here? We've been carrying this
> "FROMLIST" in our Chrome OS trees for a little while, but that's not a
> state we want to be in long-term. If it needs to spin before landing
> upstream we should get the spin out and land it. If it's OK as-is
> then it'd be nice to see it in mainline.
>
> From the above I guess Salman was waiting for Jens to weigh in with an
> opinion on the prefered bike shed color?
>
> -Doug
Powered by blists - more mailing lists