On Mon, Sep 09, 2019 at 01:49:50PM -0600, Warner Losh wrote: > On Mon, Sep 9, 2019, 5:56 AM Brooks Davis <bro...@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 <phi...@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
signature.asc
Description: PGP signature
