Date: Sat, 25 Mar 2023 16:47:42 +0100 From: Peter <pmc@citylink.dinoex.sub.org> To: freebsd-hackers@freebsd.org Subject: Re: Periodic rant about SCHED_ULE Message-ID: <ZB8Xnt/ylPy%2B4nVQ@disp.intra.daemon.contact>
next in thread | raw e-mail | index | archive | help
Quoting George Mitchell <george+freebsd@m5p.com>: >> https://forums.freebsd.org/threads/what-is-sysctl-kern-sched-preempt_thresh.85 >> >Thank you! -- George You're welcome. Can I get a success/failure report? --------------------------------------------------------------------- >> On 3/22/23, Steve Kargl <sgk@troutmask.apl.washington.edu> wrote: >>> >>> I reported the issue with ULE some 15 to 20 years ago. Can I get the PR number, please? --------------------------------------------------------------------- Test usecase: ============= Create two compute tasks competing for the same -otherwise unused- core, one without, one with syscalls: # cpuset -l 13 sh -c "while true; do :; done" & # tar cvf - / | cpuset -l 13 gzip -9 > /dev/null Within a few seconds the two task are balanced, running at nearly the same PRI and using each 50% of the core: PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 5166 root 1 88 0 13M 3264K RUN 13 9:23 51.65% sh 10675 root 1 87 0 13M 3740K CPU13 13 1:30 48.57% gzip This changes when the tar reaches /usr/include with it's many small files. Now smaller blocks are delivered to gzip, it does more syscalls, and things get ugly: PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 5166 root 1 94 0 13M 3264K RUN 13 18:07 95.10% sh 19028 root 1 81 0 13M 3740K CPU13 13 1:23 4.87% gzip This does not happen because tar would be slow in moving data to gzip: tar reads from SSD, or more likely from ARC, and this is always faster than gzip-9. The imbalance is made by the scheduler.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ZB8Xnt/ylPy%2B4nVQ>