svn commit: r351918 - head/sys/kern

Philip Paeps philip at freebsd.org
Sat Sep 7 04:23:12 UTC 2019


On 2019-09-07 12:06:32 (+0800), Warner Losh wrote:
> On Fri, Sep 6, 2019 at 9:54 PM Philip Paeps <philip at 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.

> 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


More information about the svn-src-all mailing list