From owner-svn-src-head@freebsd.org Sat Sep 7 04:23:12 2019 Return-Path: Delivered-To: svn-src-head@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DADD4E4114; Sat, 7 Sep 2019 04:23:12 +0000 (UTC) (envelope-from philip@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46QLrc48yxz4555; Sat, 7 Sep 2019 04:23:12 +0000 (UTC) (envelope-from philip@freebsd.org) Received: from weatherwax.trouble.is (weatherwax.trouble.is [IPv6:2a00:dd80:3c::62e]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "weatherwax.trouble.is", Issuer "Let's Encrypt Authority X3" (verified OK)) (Authenticated sender: philip/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 2CD5910BBF; Sat, 7 Sep 2019 04:23:12 +0000 (UTC) (envelope-from philip@freebsd.org) Received: from rincewind.trouble.is (rincewind.trouble.is [95.216.22.234]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits)) (Client CN "rincewind.trouble.is", Issuer "Let's Encrypt Authority X3" (verified OK)) by weatherwax.trouble.is (Postfix) with ESMTPS id 46QLrZ65xcz4fYg; Sat, 7 Sep 2019 04:23:10 +0000 (UTC) Received: by rincewind.trouble.is (Postfix, authenticated sender philip) id 46QLrW6pdVz1y77; Sat, 7 Sep 2019 04:23:07 +0000 (UTC) From: "Philip Paeps" To: "Warner Losh" Cc: "Ian Lepore" , src-committers , svn-src-all , svn-src-head Subject: Re: svn commit: r351918 - head/sys/kern Date: Sat, 07 Sep 2019 12:23:03 +0800 X-Clacks-Overhead: GNU Terry Pratchett X-Mailer: MailMate (1.12.5r5643) Message-ID: <9BC03B61-F8B5-476C-AD34-9DEA5230BFCF@freebsd.org> In-Reply-To: References: <201909060119.x861JWrG006910@repo.freebsd.org> <4917d7507b6ea6c360dccda261f53052aa085f2b.camel@freebsd.org> <5EE266EE-E650-48D8-9B0E-E674AD026470@freebsd.org> <3cb6429acc7e520932d2c906d1cac47540156355.camel@freebsd.org> <8F03EA29-0F3F-4321-9241-78F7C924FDE1@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Sep 2019 04:23:12 -0000 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 +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