svn commit: r351918 - head/sys/kern

[Ian Lepore]

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:
> > > Author: philip
> > > Date: Fri Sep  6 01:19:31 2019
> > > New Revision: 351918
> > > URL: https://svnweb.freebsd.org/changeset/base/351918
> > > 
> > > Log:
> > >   riscv: default to HZ=100
> > > 
> > >   Most current RISC-V development platforms are not fast enough
> > > to
> > > benefit
> > >   from the increased granularity provided by HZ=1000.
> > > 
> > >   Sponsored by:	Axiado
> > > 
> > > Modified:
> > >   head/sys/kern/subr_param.c
> > > 
> > > Modified: head/sys/kern/subr_param.c
> > > =================================================================
> > > ====
> > > =========
> > > --- head/sys/kern/subr_param.c	Fri Sep  6 00:06:55 2019	(
> > > r351
> > > 917)
> > > +++ head/sys/kern/subr_param.c	Fri Sep  6 01:19:31 2019	(
> > > r351
> > > 918)
> > > @@ -61,7 +61,7 @@ __FBSDID("$FreeBSD$");
> > >   */
> > > 
> > >  #ifndef HZ
> > > -#  if defined(__mips__) || defined(__arm__)
> > > +#  if defined(__mips__) || defined(__arm__) || defined(__riscv)
> > >  #    define	HZ 100
> > >  #  else
> > >  #    define	HZ 1000
> > > 
> > 
> > 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.
> 
> Philip
> 

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? 
I thought only ancient mips and armv5 systems still did that.  Event
timer based (so-called "tickless") systems only take timer interrupts
when actually necessary -- either because something needs to wake up at
that time, or just often enough to prevent timer rollovers, which is
typically a number like 2 or 4 hz.

-- Ian