P.S. For folks who skipped the original message, this doesn't necessarily
it at 1000.
> I'm top posting here, since this thread from a recent commit gives the
> context
>
> I'm proposing basically the following patch:
>
> diff --git a/sys/kern/subr_param.c b/sys/kern/subr_param.c
> index c0025c07eed..bb92afb6449 100644
> --- a/sys/kern/subr_param.c
> +++ b/sys/kern/subr_param.c
> @@ -61,11 +61,7 @@ __FBSDID("$FreeBSD$");
> */
>
> #ifndef HZ
> -# if defined(__mips__) || defined(__arm__) || defined(__riscv)
> -# define HZ 100
> -# else
> -# define HZ 1000
> -# endif
> +# define HZ 1000
> # ifndef HZ_VM
> # define HZ_VM 100
> # endif
>
> Along with removing HZ from almost all the kernel config files in arm and
> mips where it is already 1000. I'm agnostic about riscv, so would also be
> open to just removing the first two clauses from the #if the diff shows me
> removing.
>
> So on arm, only some of the armv5 ports have a HZ of 100: DB-78XX,
> DB-88F6XXX (but not DB-88F5XXX), DOCKSTAR, DREAMPLUG (but not SHEVAPLUG)
> and RT1310. All the armv6 and armv7 have HZ=1000. Since armv5 is slated to
> go away before 13 branches, we should just change it now. All the marvell
> parts likely should be able to cope with 1000HZ anyway, and only the RT1310
> is slow enough to maybe need HZ=100. I can't say for sure, though, since I
> can't get mine to work. armv[67] is 99%+ of the current install base, due
> to FreeBSD's need for more memory than most of the old *PLUG computers have
> anyway. So the case for arm seems fairly straight forward: bump it to 1000
> and maybe add an option line for RT1310.
>
> For mips, the situation is similar. All the atheros boards run at 1000Hz.
> BERI is the only one that sets something specific (either 100 or 200) and
> can remain. The JZ4780 stuff uses the default of 100Hz, and likely is in
> the range of machines that's neither helped nor hurt by 1000HZ. MALTA*
> also uses the default of 100HZ, but it's 100% emulation these days (or near
> enough) that we should likely keep it there. The Mediatek stuff also uses
> the default of 100HZ. It's more likely to benefit from 1000HZ, than JZ4780,
> but not by much. The XLP stuff is 1000HZ. Octeon is 100HZ, but is plenty
> fast for 1000HZ and likely would benefit from the change. So the proposal
> for that lot is to change to 1000HZ, leave BERI as is, at HZ=100 to MALTA*
> and let the rest tick over to 1000HZ by default. Should any problems arise,
> we can bump those back down to something more sane. I suspect changing to
> 1000 won't matter at all given the current mix of systems that are
> supported, with the possible exception of MALTA* (I'll defer to more recent
> users of that, though, since it has been a while for me).
>
> For riscv, which kicked all this off, I'd be inclined to leave it at 1000.
> But I don't know that market segment well enough to have an educated
> opinion.
>
> Comments?
>
> Warner
>
> On Fri, Sep 6, 2019 at 10:23 PM Philip Paeps <
[hidden email]> wrote:
>
> > On 2019-09-07 12:06:32 (+0800), Warner Losh wrote:
> > > On Fri, Sep 6, 2019 at 9:54 PM Philip Paeps <
[hidden email]>
> > > 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.
> >
> > > I have no strong opinion on riscv, but do think mips and arm should
> > > change.
> >
> > I will revert r351918 and r351919 since there is clearly no consensus.
> >
> > Let's take this discussion to arch@?
> >
> > Philip
> >
> > --
> > Philip Paeps
> > Senior Reality Engineer
> > Alternative Enterprises
> >
> _______________________________________________
>
[hidden email] mailing list
>
https://lists.freebsd.org/mailman/listinfo/freebsd-arch> To unsubscribe, send any mail to "
[hidden email]"
>
Locked
