Date: Wed, 4 Apr 2018 21:25:49 +0200 From: Peter <pmc@citylink.dinoex.sub.org> To: freebsd-stable@FreeBSD.ORG Subject: Re: kern.sched.quantum: Creepy, sadistic scheduler Message-ID: <pa38t2$1br1$1@oper.dinoex.de> In-Reply-To: <6883cf2d-207e-21ae-8d55-c768f0b72a73@FreeBSD.org> References: <pa17m7$82t$1@oper.dinoex.de> <6883cf2d-207e-21ae-8d55-c768f0b72a73@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Andriy Gapon wrote: > On 04/04/2018 03:52, Peter wrote: >> Lets run an I/O-active task, e.g, postgres VACUUM that would >> continuousely read from big files (while doing compute as well [1]): > > Not everyone has a postgres server and a suitable database. > Could you please devise a test scenario that demonstrates the problem and that > anyone could run? > Andriy, and maybe nobody anymore has such old system that is CPU-bound instead of IO-bound. I'd rather think about reproducing it on my IvyBridge. I know for sure that it is *not* specifically dependent on postgres. What I posted was the case when an endless-loop piglet starves a postgres VACUUM - and there we see a very pronounced effect of almost factor 100. When I first clearly discovered it (after a long time of belly-feeling that something behaves strange), it was postgres pg_dump (which does compression, i.e. CPU-bound) as the piglet starving an bacula-fd backup that would scan the filesystem. So, there is a general rule: we have one process that is a CPU-hog, and another process that does periodic I/O (but also *some* compute). and -important!- nothing else. If we understand the logic of the scheduler, that information should already suit for some logical verification *eg* - but I will see if I get it reprocuved on the IvyBridge machine and/or see if I get a testcase together. May take a while. P.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?pa38t2$1br1$1>