Date: Fri, 06 Sep 2019 08:18:36 -0600 From: Ian Lepore <ian@freebsd.org> To: Philip Paeps <philip@freebsd.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r351918 - head/sys/kern Message-ID: <3cb6429acc7e520932d2c906d1cac47540156355.camel@freebsd.org> In-Reply-To: <5EE266EE-E650-48D8-9B0E-E674AD026470@freebsd.org> References: <201909060119.x861JWrG006910@repo.freebsd.org> <4917d7507b6ea6c360dccda261f53052aa085f2b.camel@freebsd.org> <5EE266EE-E650-48D8-9B0E-E674AD026470@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3cb6429acc7e520932d2c906d1cac47540156355.camel>