Date: Wed, 18 Apr 2018 19:59:39 +0200 From: Peter <pmc@citylink.dinoex.sub.org> To: freebsd-stable@FreeBSD.ORG Subject: Re: kern.sched.quantum: Creepy, sadistic scheduler Message-ID: <pb812b$1eji$2@oper.dinoex.de> In-Reply-To: <2a68cfd7-6823-296d-0392-c9b12c66f6e0@m5p.com> References: <pa17m7$82t$1@oper.dinoex.de> <9FDC510B-49D0-4722-B695-6CD38CA20D4A@gmail.com> <8cfdb8a3-86a0-17ba-1e41-ff1912a30ee9@m5p.com> <20180417065617.GA95646@klump.hjerdalen.lokalnett> <CAN6yY1s7MafF18fPxgRiJVusxcbwEfK%2BGF8dKGedhXE_EUVbJA@mail.gmail.com> <CAOjFWZ47YhPFCxxhhxozUTRXY5ywPEpKrtJNaULTv37r5CFj5w@mail.gmail.com> <20180417232016.2008438c.ebfe@inbox.ru> <2a68cfd7-6823-296d-0392-c9b12c66f6e0@m5p.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi all of You, thank You very much for Your commenting and reports! From what I see, we have (at least) two rather different demands here: while George looks at the over-all speed of compute throughput, others are concerned about interactive response. My own issue is again a little bit different: I am running this small single-CPU machine as my home-office router, and it also runs a backup service, which involves compressing big files and handling an outgrown database (but that does not need to happen fast, as it's just backup stuff). So, my demand is to maintain a good balance between realtime network activity being immediately served, and low-priority batch compute jobs, while still staying responsive to shell-commands - but the over-all compute throughput is not important here. But then, I find it very difficult to devise some metrics, by which such a demand could be properly measured, to get compareable figures. George Mitchell wrote: > I suspect my case (make buildworld while running misc/dnetc) doesn't > qualify. However, I just completed a SCHED_ULE run with > preempt_thresh set to 5, and "time make buildworld" reports: > 7336.748u 677.085s 9:25:19.86 23.6% 27482+473k 42147+431581io 38010pf+0w > Much closer to SCHED_4BSD! I'll try preempt_thresh=0 next, and I > guess I'll at least try preempt_thresh=224 to see how that works > for me. -- George > I found that preempt_thresh=0 cannot be used in practice: When I try to do this on my quadcode desktop, and then start four endless-loops to get the cores busy, the (internet)radio will have a dropout every 2-3 seconds (and there is nothing else running, just a sleeping icewm and a mostly sleeping firefox)! So, the (SMP) system *depends* on preemption, it cannot handle streaming data without it. (@George: Your buildworld test is pure batch load, and may not be bothered by this effect.) I think the problem is *not* to be solved by finding a good setting for preempt_thresh (or other tuneables). I think the problem lies deeper, and these tuneables only change its appearance. I have worked out a writeup explaining my thoughts in detail, and I would be glad if You stay tuned and evaluate that. P.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?pb812b$1eji$2>