Re: svn commit: r351918 - head/sys/kern
On Mon, Sep 09, 2019 at 01:49:50PM -0600, Warner Losh wrote: > On Mon, Sep 9, 2019, 5:56 AM Brooks Davis 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 > > > > 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 +, 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
Re: svn commit: r351918 - head/sys/kern
10.09.2019 2:49, Warner Losh wrote: > 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... Several years ago I experimented with FreeBSD/MIPS32 using some real hardware that was both slow and had very small integrated flash, 8MB in total and 128KB for local configuration changes (template overrides). It used compressed root file system and standard /etc/rc.initdiskless script and its /conf/T/M/extract schema to extract local config overrides from the NVRAM very early at startup (called from /etc/rc), before /etc/rc.conf is read and before rcNG starts. Still, it's too late to change kern.hz currently. And that hardware used MIPS32 U-Boot and system had no /boot/loader at all. Maybe we could enable changing kern.hz for single user mode early at startup? ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r351918 - head/sys/kern
On Mon, Sep 9, 2019, 5:56 AM Brooks Davis 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 > > > 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 +, 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... Warner >
Re: svn commit: r351918 - head/sys/kern
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 > > 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 +, 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. -- Brooks signature.asc Description: PGP signature
Re: svn commit: r351918 - head/sys/kern
On 2019-09-07 12:06:32 (+0800), Warner Losh wrote: On Fri, Sep 6, 2019 at 9:54 PM Philip Paeps 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 +, 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 ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r351918 - head/sys/kern
On Fri, Sep 6, 2019 at 9:54 PM Philip Paeps 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 +, 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? I have no strong opinion on riscv, but do think mips and arm should change. Warner ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r351918 - head/sys/kern
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 +, 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 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. ;-) Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r351918 - head/sys/kern
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 +, 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.cFri Sep 6 00:06:55 2019(
> > > r351
> > > 917)
> > > +++ head/sys/kern/subr_param.cFri 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
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r351918 - head/sys/kern
On Fri, Sep 06, 2019 at 12:15:07PM +0800, Philip Paeps wrote:
> On 2019-09-06 11:15:12 (+0800), Ian Lepore wrote:
> > On Fri, 2019-09-06 at 01:19 +, 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.
>
Hi Philip
I only worry about HiFive Unleashed board, which is the only real hardware
available at the moment for community and it does not require this change (it
is 1.5 GHz clock).
With an amount of real silicons growing we may want to keep HZ set to 1000 in
GENERIC soon-ish so users download/build the GENERIC image and have immediate
fun.
For FPGA I usually tune (increase) timer clock frequency locally in the DTS
file based on the timing of a synthesized core.
Ruslan
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r351918 - head/sys/kern
On 2019-09-06 11:15:12 (+0800), Ian Lepore wrote:
On Fri, 2019-09-06 at 01:19 +, 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)
#defineHZ 100
# else
#defineHZ 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
--
Philip Paeps
Senior Reality Engineer
Alternative Enterprises
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r351918 - head/sys/kern
On Fri, 2019-09-06 at 01:19 +, 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.cFri Sep 6 00:06:55 2019(r351
> 917)
> +++ head/sys/kern/subr_param.cFri 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?
-- Ian
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r351918 - head/sys/kern
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(r351917)
+++ head/sys/kern/subr_param.c Fri Sep 6 01:19:31 2019(r351918)
@@ -61,7 +61,7 @@ __FBSDID("$FreeBSD$");
*/
#ifndef HZ
-# if defined(__mips__) || defined(__arm__)
+# if defined(__mips__) || defined(__arm__) || defined(__riscv)
#defineHZ 100
# else
#defineHZ 1000
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
