Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
Date:   Wed, 20 Apr 2022 11:24:08 -0700
From:   Brian Norris <briannorris@chromium.org>
To:     Mark Brown <broonie@kernel.org>
Cc:     Liam Girdwood <lgirdwood@gmail.com>,
        Matthias Kaehlcke <mka@chromium.org>,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] regulator: core: Replace _regulator_enable_delay()
 with fsleep()
Message-ID: <YmBPyJfN7we4k78/@google.com>
References: <20220418141158.1.If0fc61a894f537b052ca41572aff098cf8e7e673@changeid>
 <20220418141158.2.I31ef0014c9597d53722ab513890f839f357fdfb3@changeid>
 <YmA0vq3qkAEYGk03@sirena.org.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <YmA0vq3qkAEYGk03@sirena.org.uk>
Precedence: bulk

Hi Mark,

On Wed, Apr 20, 2022 at 05:28:46PM +0100, Mark Brown wrote:
> Did the issue with the delay functions preferring delays on the higher
> end of the allowed range get fixed?  That might be an issue for larger
> usleep() values.

Hmm, good question. I had a faint memory of this problem, and searching
around, I couldn't find that anybody *thought* they fixed it, and I
found evidence to the contrary (some reports complaining about, e.g.,
boot-time performance issues in drivers/usb due to the same, with no
indication that anybody truly fixed the problem).

And measurement on my systems (with expected usecs between 322 and 390)
show that we overshoot by the following stats (on >3000 samples, with
moderate load):

 minimum overshoot: ~3%
 maximum overshoot: ~150%
 median overshoot: ~104%
 mean overshoot: ~98%
 stddev: 0.207

I guess this is one aspect that Documentation/timers/timers-howto.rst is
referring to, when it says: "Exact tolerances here are very situation
specific, thus it is left to the caller to determine a reasonable
range." It feels like fsleep()'s "x2" is pretty arbitrary and often not
what people want, but maybe it's good enough for non-sensitive cases.

So maybe it's better to retain the regulator core helper
(_regulator_enable_delay()) and rename/repurpose it for my patch 1?

I feel like there's some room for improvement in either fsleep() or
usleep_range() or both, but I'm not sure exactly how to go about that
right now.

Brian