mlel...@serpens.de (Michael van Elst) writes:
>Either direction mstohz or hztoms should better always round up to
>guarantee a minimal delay.
And both should be replaced by hztous()/ustohz().
Microseconds allow a time value of ~35 minutes as 32bit signed
integer, which should be a safe range
mo...@rodents-montreal.org (Mouse) writes:
>How heavily is hztoms used? (I would expect mstohz to be used far more
>heavily.)
sys/dev/acpi/acpi_cpu_cstate.c: sc->sc_cstate_sleep =
hztoms(acpitimer_delta(end, start)) * 1000;
sys/dev/spkr_audio.c: audiobell(sc->sc_audiodev, xhz,
> But the x86_64 code appears to return to the same instruction, banging its h$
> It's my belief that the alpha behavior is more desirable.
> Please, discuss.
I could argue that either way.
In some cases, you want to re-execute the instruction. A simple
example is "FPU disabled" on
On Wed, 26 May 2021, Jason Thorpe wrote:
...
The alpha code has, for a very long time, always advanced the PC past
the faulting instruction on an arithmetic trap[1]. This, in essence,
makes it behave exactly as if the exception were disabled, while still
giving the handler a chance to "do
I've been working on fixing some test case failures on the Alpha port, and I'm
elbow-deep in FP-land right now. The Alpha has a somewhat complicated FP story
because it has architecture-mandated software completion for essentially
anything outside the happy path in hardware, and to support
> # define hztoms(t) ((unsigned int)(((t) + 0ul) * 1000ul / hz))
> when hz > 1000, this returns 0 for input of 1.
True, which is correct - when hz > 1000, one tick is less than one
millisecond.
If, that is, it's defined to round down (and, if not, the
implementation you quote is broken). What
> > Me too. I was - am - rather puzzled by it.
>
> Right. That was my issue. Claiming that you'd get more problems with
> rounding and issues with coarsness when running at a higher frequency,
> when it in fact is the exact opposite. With a higher frequency you have
> more accuracy and less
On 2021-05-26 12:59, Mouse wrote:
I don't fully understand the discussion here.
Initially people claimed that HZ at 8000 would be a problem,
Well, my experience indicates that it _is_ a problem, at least when
using disks at piixide (or pciide).
Right. But not for the reason suggested. But
> I don't fully understand the discussion here.
> Initially people claimed that HZ at 8000 would be a problem,
Well, my experience indicates that it _is_ a problem, at least when
using disks at piixide (or pciide).
> which for me seems a bit backwards.
Me too. I was - am - rather puzzled by
On 2021-05-26 11:12, matthew green wrote:
Manuel Bouyer writes:
On Wed, May 26, 2021 at 05:35:53PM +1000, matthew green wrote:
Manuel Bouyer writes:
On Tue, May 25, 2021 at 10:46:04PM -, Michael van Elst wrote:
bou...@antioche.eu.org (Manuel Bouyer) writes:
Another issue could be
Manuel Bouyer writes:
> On Wed, May 26, 2021 at 05:35:53PM +1000, matthew green wrote:
> > Manuel Bouyer writes:
> > > On Tue, May 25, 2021 at 10:46:04PM -, Michael van Elst wrote:
> > > > bou...@antioche.eu.org (Manuel Bouyer) writes:
> > > >
> > > > >Another issue could be mstohz() called
On Wed, May 26, 2021 at 05:35:53PM +1000, matthew green wrote:
> Manuel Bouyer writes:
> > On Tue, May 25, 2021 at 10:46:04PM -, Michael van Elst wrote:
> > > bou...@antioche.eu.org (Manuel Bouyer) writes:
> > >
> > > >Another issue could be mstohz() called with a delay too short;
> > >
Manuel Bouyer writes:
> On Tue, May 25, 2021 at 10:46:04PM -, Michael van Elst wrote:
> > bou...@antioche.eu.org (Manuel Bouyer) writes:
> >
> > >Another issue could be mstohz() called with a delay too short;
> > >mstohz() will round it up to 1 tick.
> >
> >
> > # define mstohz(ms)
On Tue, May 25, 2021 at 10:46:04PM -, Michael van Elst wrote:
> bou...@antioche.eu.org (Manuel Bouyer) writes:
>
> >Another issue could be mstohz() called with a delay too short;
> >mstohz() will round it up to 1 tick.
>
>
> # define mstohz(ms) ((unsigned int)((ms + 0ul) * hz / 1000ul))
>
14 matches
Mail list logo
