Date: Thu, 9 Jun 2016 11:13:40 -0400 From: Warner Losh <wlosh@bsdimp.com> To: Ian Lepore <ian@freebsd.org> Cc: Gergely Imreh <imrehg@gmail.com>, FreeBSD ARM <freebsd-arm@freebsd.org> Subject: Re: RPi2 i/o blocking and SD card performance Message-ID: <6DCCB49C-164D-4829-9578-1B49EA81CF01@bsdimp.com> In-Reply-To: <1465483247.1188.60.camel@freebsd.org> References: <CAJ3iQcoc5nVSFz3JKMG_Y9Q9k4PFizmp2rf3vfA7nv=u_12nBQ@mail.gmail.com> <6406AECE-0153-494F-88EE-E58C8357FC1B@bsdimp.com> <1465483247.1188.60.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Jun 9, 2016, at 10:40 AM, Ian Lepore <ian@freebsd.org> wrote: >=20 > On Thu, 2016-06-09 at 09:55 -0400, Warner Losh wrote: >>> On Jun 9, 2016, at 5:37 AM, Gergely Imreh <imrehg@gmail.com> wrote: >>>=20 >>> Hi, >>>=20 >>> I've been testing FreeBSD 11.0-CURRENT on a RaspberryPi2. I'm = relatively >>> new to FreeBSD, and wondering if there's any advice for improving = the >>> performance a bit. >>>=20 >>> First, it looks like there's a lot of i/o blocking behaviour going = on. For >>> example running MediaWiki on the board, if I compile any ports, the = site >>> itself is pretty much unusable (the PHP scripts time out even with = 180s >>> timeouts). The strangest thing is that the CPU usage is not at 100% = all the >>> way, can be that all 4 cores are ~99% idle, and still everything = goes very >>> slow. Once the ports compilation or any other i/o-related task is = finished, >>> it's snappy again. >>>=20 >>> Any idea why it could be to have such big latency/lag even though = the CPU >>> is idle? Is there anything I could test? >>=20 >> What=C2=B4s the HZ for the system? The sd/mmc system has a lot of = context switches >> may be one reason for this. >=20 > What does HZ have to do with it? That's a serious question I've been > asking for about 3 years now, and have not gotten an answer (any = answer > from anyone): "What influence does HZ have on modern freebsd?" = (Modern > meaning roughly "with eventtimers implemented and the ULE scheduler.") >=20 > The little bit of testing I've tried to do hasn't shown any difference > at all that I can detect between HZ=3D100 and HZ=3D5000, or any values > in-between. That=E2=80=99s a good data point. Once upon a time there were places in = the SD stack where there were 1 tick sleeps that would show a big difference in the = latency=20 because of them. If you aren=E2=80=99t seeing any difference, those must = be officially dead. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6DCCB49C-164D-4829-9578-1B49EA81CF01>