Date: Sat, 25 Mar 2023 13:41:16 -0700 From: Mark Millard <marklmi@yahoo.com> To: Peter <pmc@citylink.dinoex.sub.org> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: Periodic rant about SCHED_ULE Message-ID: <E67A639B-AE86-4632-A2F6-FF637E020A90@yahoo.com> In-Reply-To: <ZB9Ebx2/Eo/GQzDl@disp.intra.daemon.contact> References: <5AF26266-5B4C-4A7F-8784-4C6308B6C5CA.ref@yahoo.com> <5AF26266-5B4C-4A7F-8784-4C6308B6C5CA@yahoo.com> <ZB9Ebx2/Eo/GQzDl@disp.intra.daemon.contact>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mar 25, 2023, at 11:58, Peter <pmc@citylink.dinoex.sub.org> wrote: > On Sat, Mar 25, 2023 at 11:14:11AM -0700, Mark Millard wrote: >=20 > ! Why did PID 10675 change to 19028? >=20 > Because it went into some NFS share, and it would still be there if I > hadn't restartet it a bit differently. >=20 > ! When I tried that tar line, I get lots of output to stderr: > !=20 > ! # tar cvf - / | cpuset -l 13 gzip -9 > /dev/null > ! tar: Removing leading '/' from member names > ! a . > ! a root > ! a wrkdirs > ! a bin > ! a usr > ! . . . > !=20 > ! Was that an intentional part of the test? >=20 > Yes. So you can see what it is currently feeding to gzip (small or > big files - or some NFS share, where the operation becomes pointless). >=20 > ! # tar cvf - / 2>/dev/null | cpuset -l 13 gzip -9 2>&1 > /dev/null I should have had at the the order >/dev/null 2>&1 Sorry. > !=20 > ! At which point I get the likes of: > !=20 > ! 17129 root 1 68 0 14192Ki 3628Ki RUN 13 0:20 = 3.95% gzip -9 > ! 17128 root 1 20 0 58300Ki 13880Ki pipdwt 18 0:00 = 0.27% tar cvf - / (bsdtar) > ! 17097 root 1 133 0 13364Ki 3060Ki CPU13 13 8:05 = 95.93% sh -c while true; do :; done > !=20 > ! up front. >=20 > Ah. So? To me this doesn't look good. If both jobs are runnable, they > should each get ~50%. >=20 > ! For reference, I also see the likes of the following from > ! "gstat -spod" (it is a root on ZFS context with PCIe Optane media): >=20 > So we might assume that indeed both jobs are runable, and the only > significant difference is that one does system calls while the other > doesn't. >=20 > The point of this all is: identify the malfunction with the most > simple usecase. (And for me here is a malfunction.) > And then, obviousely, fix it. I tried the following that still involves pipe-io but avoids file system I/O (so: simplifying even more): cat /dev/random | cpuset -l 13 gzip -9 >/dev/null 2>&1 mixed with: cpuset -l 13 sh -c "while true; do :; done" & So far what I've observed is just the likes of: 17736 root 1 112 0 13364Ki 3048Ki RUN 13 2:03 = 53.15% sh -c while true; do :; done 17735 root 1 111 0 14192Ki 3676Ki CPU13 13 2:20 = 46.84% gzip -9 17734 root 1 23 0 12704Ki 2364Ki pipewr 24 0:14 = 4.81% cat /dev/random Simplifying this much seems to get a different result. Pipe I/O of itself does not appear to lead to the behavior you are worried about. Trying cat /dev/zero instead ends up similar: 17778 root 1 111 0 14192Ki 3672Ki CPU13 13 0:20 = 51.11% gzip -9 17777 root 1 24 0 12704Ki 2364Ki pipewr 30 0:02 = 5.77% cat /dev/zero 17736 root 1 112 0 13364Ki 3048Ki RUN 13 6:36 = 48.89% sh -c while true; do :; done It seems that, compared to using tar and a file system, there is some significant difference in context that leads to the behavioral difference. It would probably be of interest to know what the distinction(s) are in order to have a clue how to interpret the results. =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E67A639B-AE86-4632-A2F6-FF637E020A90>