All of
 help / color / mirror / Atom feed
From: Corey Minyard <>
To: Tejun Heo <>
Subject: Re: [PATCH] ipmi_si_intf: use usleep_range() instead of busy looping
Date: Wed, 10 Jul 2019 15:11:32 -0500	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Wed, Jul 10, 2019 at 07:22:21AM -0700, Tejun Heo wrote:
> Hello,
> > > We can go for shorter timeouts for sure but I don't think this sort of
> > > busy looping is acceptable.  Is your position that this must be a busy
> > > loop?
> > 
> > Well, no.  I want something that provides as high a throughput as
> > possible and doesn't cause scheduling issues.  But that may not be
> > possible.  Screwing up the scheduler is a lot worse than slow IPMI
> > firmware updates.
> > 
> > How short can the timeouts be and avoid issues?
> We first tried msleep(1) and that was too slow even for sensor reading
> making it take longer than 50s.  With the 100us-200us sleep, it got
> down to ~5s which was good enough for our use case and the cpu /
> scheduler impact was still mostly negligible.  I can't tell for sure
> without testing but going significantly below 100us is likely to
> become visible pretty quickly.

What was the time to read the sensors before you did the change?
It depends a lot on the system, so I can't really guess.

> We can also take a hybrid approach where we busy poll w/ 1us udelay
> upto, say, fifty times and then switch to sleeping poll.

I'm pretty sure we didn't try that in the original work, but I'm
not sure that would work.  Most of the initial spinning would be

I would guess that you would decrease the delay and the performance
would improve linearly until you hit a certain point, and then
decreasing the delay wouldn't make a big difference.  That's the
point you want to use, I think.

What might actually be best would be for the driver to measure the
time it takes the BMC to respond and try to set the timeout based
on that information.  BMCs vary a lot, a constant probably won't

And I was just saying that I wasn't expecting any big changes in
the IPMI driver any more...

> Are there some tests which can be used to verify the cases which may
> get impacted by these changes?

Unfortunately not.  The original people at Dell that did the work
don't work there any more, I don't think.

I mostly use qemu now for testing, but this is not something you can
really simulate on qemu very well.  Can you do an IPMI firmware
update on your system?  That would be the easiest way to measure.



> Thanks.
> -- 
> tejun

  reply	other threads:[~2019-07-10 20:11 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-09 21:06 Tejun Heo
2019-07-09 21:46 ` Corey Minyard
2019-07-09 22:09   ` Tejun Heo
2019-07-09 23:01     ` Corey Minyard
2019-07-10 14:22       ` Tejun Heo
2019-07-10 20:11         ` Corey Minyard [this message]
2019-08-01 17:40         ` Corey Minyard
2019-08-05 18:18           ` Tejun Heo
2019-08-05 21:18             ` Corey Minyard
2019-08-07 18:27               ` Tejun Heo
2019-07-09 22:11   ` Tejun Heo
2019-07-09 23:07     ` [Openipmi-developer] " Corey Minyard
2019-07-10 14:12       ` Tejun Heo

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \
    --subject='Re: [PATCH] ipmi_si_intf: use usleep_range() instead of busy looping' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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.