Date: Tue, 10 Sep 2019 08:12:54 +0000 From: Brooks Davis <brooks@freebsd.org> To: Warner Losh <imp@bsdimp.com> Cc: Philip Paeps <philip@freebsd.org>, Ian Lepore <ian@freebsd.org>, src-committers <src-committers@freebsd.org>, svn-src-all <svn-src-all@freebsd.org>, svn-src-head <svn-src-head@freebsd.org> Subject: Re: svn commit: r351918 - head/sys/kern Message-ID: <20190910081254.GC41333@spindle.one-eyed-alien.net> In-Reply-To: <CANCZdfrxUTsb_dRKjcd6kKcDLSxSJge3hDo74mf4fZODOJN6XA@mail.gmail.com> References: <201909060119.x861JWrG006910@repo.freebsd.org> <4917d7507b6ea6c360dccda261f53052aa085f2b.camel@freebsd.org> <5EE266EE-E650-48D8-9B0E-E674AD026470@freebsd.org> <3cb6429acc7e520932d2c906d1cac47540156355.camel@freebsd.org> <8F03EA29-0F3F-4321-9241-78F7C924FDE1@freebsd.org> <CANCZdfr6pz19NCLmsua6iGzusotrcHN=u47RH7Y1PdM4rnomZA@mail.gmail.com> <9BC03B61-F8B5-476C-AD34-9DEA5230BFCF@freebsd.org> <20190909115632.GB41333@spindle.one-eyed-alien.net> <CANCZdfrxUTsb_dRKjcd6kKcDLSxSJge3hDo74mf4fZODOJN6XA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--JgQwtEuHJzHdouWu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 09, 2019 at 01:49:50PM -0600, Warner Losh wrote: > On Mon, Sep 9, 2019, 5:56 AM Brooks Davis <brooks@freebsd.org> wrote: >=20 > > 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@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=3D100 > > > >>>>> > > > >>>>> This seems like a bad idea. I've run a 90mhz armv4 chip with > > > >>>>> HZ=3D1000 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 st= ill > > > >>>>> 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 lo= ng > > > >>>>> 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=3D100= 0 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 a= nd > > > >>>> FPGA prototypes) I've encountered are running slower than the > > > >>>> tipping point where HZ=3D1000 makes sense. With the default of > > > >>>> HZ=3D100, faster exceptions can still set HZ=3D1000 in their ind= ividual > > > >>>> 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=3D1000 by default and HZ=3D100 in the confi= g 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=3D100 feels like a more sen= sible > > > >> default than HZ=3D1000. > > > > > > > > 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 !=3Dv5 is also 1000Hz, so it sh= ould > > > > 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=3D100 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 tak= es > > > 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. >=20 > Would your needs be adequately covered by the current mechanisms to set H= Z? > 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 --JgQwtEuHJzHdouWu Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJdd1sFAAoJEKzQXbSebgfA5rsH/3FnBhgLccO5ab/LWKIqVNra s0E8LeG0NVshi46Ooyh9g2g5qhsV7Z+2cyG8OBBkFvWfYiM4JNI29k6GmkfReNAq njJASuniOwR49q6tiR0qy79gnXq8GpfNJ2X6NM9jTrdRsTL1Q4XLX92eWNZnZTZz uTREBt2koi0tQe0hZ40tZJOxt+wy/mnxtuh183ouO64zK8DSIhvlTNwssS9zqPzJ UmTZQuuXJO1vJhdJjWHVX2krn1IfgL4P2FbdeQPFLXi8qDKpojNMO/oqMd4XMIbp HIN1XybfoInX/+92uvtaAoFJPMx1yoVOqFsFLTWjzNA+Nn4hEGgqX32WW6FfULs= =t4lh -----END PGP SIGNATURE----- --JgQwtEuHJzHdouWu--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190910081254.GC41333>