Date: Tue, 13 Jul 2021 18:53:14 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 257160] SCHED_4BSD produces nonsense in top. Message-ID: <bug-257160-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D257160 Bug ID: 257160 Summary: SCHED_4BSD produces nonsense in top. Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: dgilbert@eicat.ca While I'm testing this on riscv64, I strongly suspect that it's not architecture dependant. It may, however, depend on having a multi-cpu syst= em. Due to the nature of my quad-core risv64 (it's slow) and what I want to do = with it(it's fairly busy), I was annoyed that SCHED_ULE was mostly ignoring my n= ice levels giving more than 0 time to processes marked as nice -20 vs. processes not nice. Anyways, I installed a kernel with SCHED_4BSD. Keep in mind this is a quad core CPU: PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMM= AND 604 dgilbert 1 45 0 109M 66M CPU3 3 0:02 1039.89% c++ 605 dgilbert 1 45 0 109M 66M CPU1 1 0:02 1031.29% c++ 606 dgilbert 1 45 0 109M 66M RUN 2 0:02 1020.32% c++ 603 dgilbert 1 44 0 109M 66M CPU0 0 0:02 1011.41% c++ 854 root 1 40 0 17M 4764K select 1 3:04 0.17% tmux 425 root 1 40 0 14M 4040K CPU2 2 0:03 0.15% top ... that is a sample top output --- and the >100% _single thread_ processes continue to be significantly more than 100% until they die. Obviously, top is not reporting reality here. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-257160-227>