svn commit: r351918 - head/sys/kern

Tue Sep 10 08:12:56 UTC 2019

On Mon, Sep 09, 2019 at 01:49:50PM -0600, Warner Losh wrote:
> On Mon, Sep 9, 2019, 5:56 AM Brooks Davis <brooks at freebsd.org> wrote:
> 
> > On Sat, Sep 07, 2019 at 12:23:03PM +0800, Philip Paeps wrote:
> > > On 2019-09-07 12:06:32 (+0800), Warner Losh wrote:
> > > > On Fri, Sep 6, 2019 at 9:54 PM Philip Paeps <philip at freebsd.org>
> > > > wrote:
> > > >> On 2019-09-06 22:18:36 (+0800), Ian Lepore wrote:
> > > >>> On Fri, 2019-09-06 at 12:15 +0800, Philip Paeps wrote:
> > > >>>> On 2019-09-06 11:15:12 (+0800), Ian Lepore wrote:
> > > >>>>> On Fri, 2019-09-06 at 01:19 +0000, Philip Paeps wrote:
> > > >>>>>> Log:
> > > >>>>>>   riscv: default to HZ=100
> > > >>>>>
> > > >>>>> This seems like a bad idea.  I've run a 90mhz armv4 chip with
> > > >>>>> HZ=1000 and didn't notice any performance hit from doing so.
> > > >>>>> Almost all arm kernel config files set HZ as an option, so that
> > > >>>>> define doesn't do much for arm these days.  It probably does still
> > > >>>>> set HZ for various mips platforms.
> > > >>>>>
> > > >>>>> I would think 1000 is appropriate for anything modern running at
> > > >>>>> 200mhz or more.
> > > >>>>>
> > > >>>>> Setting it to 100 has the bad side effect of making things like
> > > >>>>> msleep(), tsleep(), and pause() (which show up in plenty of
> > > >>>>> drivers) all have a minimum timeout of 10ms, which is a long long
> > > >>>>> time on modern hardware.
> > > >>>>>
> > > >>>>> What benefit do you think you'll get from the lower number?
> > > >>>>
> > > >>>> On systems running at 10s of MHz (or slower, ick), with HZ=1000 you
> > > >>>> spend an awful lot of time servicing the timer interrupt and not
> > > >>>> very much time doing anything else.
> > > >>>>
> > > >>>> My rationale was that most RISC-V systems (including emulation and
> > > >>>> FPGA prototypes) I've encountered are running slower than the
> > > >>>> tipping point where HZ=1000 makes sense.  With the default of
> > > >>>> HZ=100, faster exceptions can still set HZ=1000 in their individual
> > > >>>> configs.
> > > >>>>
> > > >>>> When the RISC-V world evolves to having more actual silicon and
> > > >>>> fewer slow prototypes, I definitely agree this default should be
> > > >>>> flipped again for HZ=1000 by default and HZ=100 in the config files
> > > >>>> for the exceptions.
> > > >>>
> > > >>> Wait a second... are you saying that the riscv implementation
> > > >>> doesn't support event timers and uses an old-style periodic tick
> > > >>> based on HZ?
> > > >>
> > > >> Depending on the hardware, there may not be an event timer (yet)...
> > > >>
> > > >> As I wrote: I would be more than happy to revert this change when
> > > >> more silicon becomes available.  Presently, there is exactly one
> > > >> silicon RISC-V implementation commercially available (HiFive FU540)
> > > >> and even that one is kind of difficult to source.  Most people
> > > >> running RISC-V are doing so in emulation or on FPGAs.
> > > >>
> > > >> Given how long these things take to boot to userland (where you
> > > >> really notice how slow things are), HZ=100 feels like a more sensible
> > > >> default than HZ=1000.
> > > >
> > > > I think it show more that the defaults are bad for MIPS and ARM. All
> > > > the MIPS files, except BERI/CHERI are 1000Hz. Well, Octeon is also
> > > > 100Hz, due to the defaults, but it will be fine at 1000Hz, so maybe we
> > > > need to attend to this as well. Arm !=v5 is also 1000Hz, so it should
> > > > be changed...
> > > >
> > > >> I don't feel terribly strongly about this though.  I've just been
> > > >> bitten several times in the last week on a <15MHz FPGA forgetting to
> > > >> set HZ=100 in config and figured I'd save others the trouble. ;-)
> > > >
> > > > 15MHz FPGA? FreeBSD 1.0 barely ran on 25MHz i386 machines of the
> > > > time....  How common are these beasts and how well does FreeBSD do on
> > > > them. I assume these are early prototypes?
> > >
> > > These are early prototypes indeed.
> > >
> > > FreeBSD runs remarkably well on them.  Slowly of course.  Booting takes
> > > several minutes and running anything non-trivial can be frustrating.
> >
> > [More context for Warner and others following along.]
> >
> > I don't know what platform Philip is using here, but with architectures
> > supporting CHERI (including MIPS and RISC-V), we typically run on
> > sub-100Mhz FPGA implementations.
> >
> > We also run on simulations or models that range from 100s of MIPS to a
> > few KIPS.  Being able to do this is important to help validate that the
> > models we're proving security properties on actually relate to the
> > "more real" implementations we develop on.
> >
> > In all these cases, "run" is a relative thing.  We certainly don't
> > expect to self-host until we've got performant hardware (and to the
> > extent that we care about 32-bit, we consider self-hosting an active
> > non-goal.)  We often expect to be able to run real software including
> > things like nginx and webkit, but we mostly care about relative
> > performance not interactivity.
> 
> Would your needs be adequately covered by the current mechanisms to set HZ?
> This just covers the defaults for the whole platform. As always, these can
> be overridden in the boot loader or kernel config file...

Yeah, the current mechanisms are fine.  I just wanted to clarify that
we're asking different things from the platform then we did of a 25MHz
i386.

-- Brooks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-src-all/attachments/20190910/58b0a8d0/attachment.sig>