From: Alex Elder <aelder@sgi.com>
To: Dave Chinner <david@fromorbit.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH] xfs: force background CIL push under sustained load
Date: Fri, 24 Sep 2010 09:02:39 -0500 [thread overview]
Message-ID: <1285336959.1974.11.camel@doink> (raw)
In-Reply-To: <20100924011855.GR2614@dastard>
On Fri, 2010-09-24 at 11:18 +1000, Dave Chinner wrote:
> On Thu, Sep 23, 2010 at 01:53:55PM -0500, Alex Elder wrote:
> > On Thu, 2010-09-23 at 12:27 +1000, Dave Chinner wrote:
. . .
> > I don't really care much about this, but I'll take this
> > opportunity for a small rant.
> >
> > The difference in calculation cost/speed between "x >> 3" and
> > "x / 8" is vanishingly small.
>
> That is architecture dependent, but in most cases these days the
> compiler will optimise a divide-by-power-of−2-constant into a shift
> operation anyway. I'm pretty sure that optimisation is done on even
> on x86 as a shift is a single cycle operation while an integer
> divide still takes several cycles and consumes more power.
I know, it'll take about a nanosecond longer than necessary,
and an extra 25 picowatt hours (IF the compiler doesn't optimize
it away). This being done to determine whether to start a series
of I/O operations...
> > I think it is meaningful to use
> > a shift in places where a power-of-two is mandated, but in places
> > like this it suggests there is a constraint that simply doesn't
> > exist. So for example, you could have chosen (log->logsize / 10)
> > as the "try pushing" value, and (log->logsize / 4 - 1) as the
> > "must push" value.
>
> It's more the fact that XFS uses power-of-2 logic (i.e shifts)
> everywhere. I just tend to be consistent with what is already there.
> In this case, the AIL push thresholds are calculated using shifts:
>
> free_threshold = MAX(free_threshold, (log->l_logBBsize >> 2));
>
> and so when you compare that to the XLOG_CIL_SPACE_LIMIT()
> definitions, it is immediately clear that the CIL limits are smaller
> than the AIL push threshold...
I get it. And as I said before, I truly don't care much about
this--it's an observation more than even an annoyance, and it's
already taken a lot more time and mental energy (not to mention
electric power) than it ever really deserved.
-Alex
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2010-09-24 14:01 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-23 2:27 [PATCH] xfs: force background CIL push under sustained load Dave Chinner
2010-09-23 10:43 ` Christoph Hellwig
2010-09-23 18:53 ` Alex Elder
2010-09-24 1:18 ` Dave Chinner
2010-09-24 14:02 ` Alex Elder [this message]
2010-09-23 18:58 ` Alex Elder
2010-09-24 2:15 ` Dave Chinner
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=1285336959.1974.11.camel@doink \
--to=aelder@sgi.com \
--cc=david@fromorbit.com \
--cc=xfs@oss.sgi.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.