Re: ULE nice behavior fixed.
On Thu, Apr 03, 2003 at 02:31:01AM -0500, Jeff Roberson [EMAIL PROTECTED] wrote: Interactivity is still worse under ULE. It's quite noticeable and I tested it on two SMP boxes by running two simple loops in kind of: for ((;;)); do let $((4+4)); done # this is bash specific The loops ran under nice +20. Typing in the xterm is jerky, characters will not show up immediately, but in small bursts. I mean that about three characters typed in will show up immediately, then small pause happens and a burst of characters (which queued up in the pause) will show up. This is annoying. Starting up xterm takes more time as well, but I can live with that. This is strange, I am not seeing any of this behavior. What is the version of your sched_ule.c? I made more changes very recently. /usr/src/sys/kern/sched_ule.c: $FreeBSD: src/sys/kern/sched_ule.c,v 1.19 2003/04/02 08:22:33 jeff Exp $ I see it's up to version 1.20 now, will it matter? ULE seems faster to me than 4BSD when the loops aren't running or only one loop is running. Anyway, you are definitely making progress in huge steps, it's much-much better than it was when you first committed it. Thank you. -- Vallo Kallaste ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE nice behavior fixed.
On (2003/04/02 01:54), Jeff Roberson wrote: It probably still needs some tweaking but it seems to be MUCH better now. New algorithm entirely. nice +20 processes will not run if anything else wants to. Some of us have been waiting for that behaviour for a long time (long before you started working on ULE). Thanks very much! Ciao, Sheldon. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE nice behavior fixed.
On Wed, 2 Apr 2003, Sheldon Hearn wrote: On (2003/04/02 01:54), Jeff Roberson wrote: It probably still needs some tweaking but it seems to be MUCH better now. New algorithm entirely. nice +20 processes will not run if anything else wants to. Some of us have been waiting for that behaviour for a long time (long before you started working on ULE). Er, this is the normal behaviour in FreeBSD-3.0 through FreeBSD-4.8, so you shouldn't have waited more than negative 4 years for it :-). The strict implementation of this behaviour in these releases causes priority inversion problems, but the problems apparently aren't very important. The scaling of niceness was re-broken in -current about 3 years ago to fix the priority inversion problems. This is with SCHED_4BSD. SCHED_ULE has larger problems. Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE nice behavior fixed.
On (2003/04/02 21:48), Bruce Evans wrote: Some of us have been waiting for that behaviour for a long time (long before you started working on ULE). Er, this is the normal behaviour in FreeBSD-3.0 through FreeBSD-4.8, so you shouldn't have waited more than negative 4 years for it :-). The strict implementation of this behaviour in these releases causes priority inversion problems, but the problems apparently aren't very important. The scaling of niceness was re-broken in -current about 3 years ago to fix the priority inversion problems. I should have realized that a long time would mean different things to different people, with respect to HEAD. I remember being involved in a flamefest on this issue a few years back. You were involved too. :-) However, are you sure the nice 20 only gets unwanted CPU behaviour is actually what you get in RELENG_4 (as opposed to your heavily patched version)? Ciao, Sheldon. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE nice behavior fixed.
On Wed, 2 Apr 2003, Sheldon Hearn wrote: On (2003/04/02 21:48), Bruce Evans wrote: Some of us have been waiting for that behaviour for a long time (long before you started working on ULE). Er, this is the normal behaviour in FreeBSD-3.0 through FreeBSD-4.8, so you shouldn't have waited more than negative 4 years for it :-). The strict implementation of this behaviour in these releases causes priority inversion problems, but the problems apparently aren't very important. The scaling of niceness was re-broken in -current about 3 years ago to fix the priority inversion problems. I should have realized that a long time would mean different things to different people, with respect to HEAD. I remember being involved in a flamefest on this issue a few years back. You were involved too. :-) However, are you sure the nice 20 only gets unwanted CPU behaviour is actually what you get in RELENG_4 (as opposed to your heavily patched version)? I tested RELENG_4 while replying :-). I don't have any significant patches in it. nice 20 only gets unwanted CPU was the intended behaviour, and it still seems to work. I found it hard to see it working since I used 2.5-months-noncurrent -current utilities. I use some hacks to unbreak things like test(1) using a syscall that doesn't exist in RELENG_4, but the hacks don't extend to making ps or top work, so I couldn't use them to see what the processes were doing. Normally I use simple tests like: %%% for i in 0 20 do nice -$i sh -c while :; do echo -n;done done top -o time %%% to debug scheduling of long-running (cpu hog) processes. If niceness is working right, then the priority of the nice +0 should never reach that of the nice +20 process (actually the actual priorities (actual = displayed + PZERO) mod 4). You can normally see what is happening by watching top for a while and predict what will/should happen with some practice. Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE nice behavior fixed.
On Wed, 2 Apr 2003 16:24, Jeff Roberson wrote: It probably still needs some tweaking but it seems to be MUCH better now. New algorithm entirely. nice +20 processes will not run if anything else wants to. idleprio is still not working correctly. bde reports that this causes a 3% perf degradation for buildworld. Isn't nice +20 == idle prio then? My understanding was that idle prio didn't run unless nothing else wanted the CPU which is what you describe nice +20 as doing :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE nice behavior fixed.
On Thu, 3 Apr 2003, Daniel O'Connor wrote: On Wed, 2 Apr 2003 16:24, Jeff Roberson wrote: It probably still needs some tweaking but it seems to be MUCH better now. New algorithm entirely. nice +20 processes will not run if anything else wants to. idleprio is still not working correctly. bde reports that this causes a 3% perf degradation for buildworld. Isn't nice +20 == idle prio then? My understanding was that idle prio didn't run unless nothing else wanted the CPU which is what you describe nice +20 as doing :) It's actually a seperate priority class. It doesn't have anything to do with nice. This is now fixed in ULE. We treat the classes specially now where before everything went onto the same run queue. Cheers, Jeff ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE nice behavior fixed.
On Wed, 2 Apr 2003, Bruce Evans wrote: On Wed, 2 Apr 2003, Sheldon Hearn wrote: On (2003/04/02 01:54), Jeff Roberson wrote: It probably still needs some tweaking but it seems to be MUCH better now. New algorithm entirely. nice +20 processes will not run if anything else wants to. Some of us have been waiting for that behaviour for a long time (long before you started working on ULE). Er, this is the normal behaviour in FreeBSD-3.0 through FreeBSD-4.8, so you shouldn't have waited more than negative 4 years for it :-). The strict implementation of this behaviour in these releases causes priority inversion problems, but the problems apparently aren't very important. The scaling of niceness was re-broken in -current about 3 years ago to fix the priority inversion problems. This is with SCHED_4BSD. SCHED_ULE has larger problems. Do you know of any problem other than idlepri breakage? I just fixed that. I'm about to get on a plane so I don't have time to benchmark it. If you have a chance I'd love to see how the most recent fixes effect your buildworld time. I still have to microoptimize the code a bit to get rid of switch statements etc, but it all works. Cheers, Jeff ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE nice behavior fixed.
On Wed, 2 Apr 2003, Jeff Roberson wrote: On Wed, 2 Apr 2003, Bruce Evans wrote: ... The scaling of niceness was re-broken in -current about 3 years ago to fix the priority inversion problems. This is with SCHED_4BSD. SCHED_ULE has larger problems. Do you know of any problem other than idlepri breakage? I just fixed that. I'm about to get on a plane so I don't have time to benchmark it. If you have a chance I'd love to see how the most recent fixes effect your buildworld time. Nothing very important. Many scheduler-related fields shown by ps are now useless since they only have a dummy entry in them. IIRC, one is worse than useless since the dummy entry doesn't fit in the field width. Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE nice behavior fixed.
On Thu, 3 Apr 2003, Bruce Evans wrote: On Wed, 2 Apr 2003, Jeff Roberson wrote: On Wed, 2 Apr 2003, Bruce Evans wrote: ... The scaling of niceness was re-broken in -current about 3 years ago to fix the priority inversion problems. This is with SCHED_4BSD. SCHED_ULE has larger problems. Do you know of any problem other than idlepri breakage? I just fixed that. I'm about to get on a plane so I don't have time to benchmark it. If you have a chance I'd love to see how the most recent fixes effect your buildworld time. Nothing very important. Many scheduler-related fields shown by ps are now useless since they only have a dummy entry in them. IIRC, one is worse than useless since the dummy entry doesn't fit in the field width. Ah, right, you're talking about the weighted cpu? Some of these corners need to be cleaned up. I wanted to get other behavior cleaned up first. What is your impression of ULE? What do you think would be required for it to become the default scheduler? I mean, other than lots of time and benchmarking to prove it. I need to work on the cpu rebalancing code a bit more. I also want to do a fuzzy rescheduling mode that will notice how many interactive threads there are and mi_switch less agressively if there are none. My measurements show that this could have a huge perf impact on some workloads. Cheers, Jeff ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE nice behavior fixed.
On Thu, 3 Apr 2003, Daniel O'Connor wrote: On Wed, 2 Apr 2003 16:24, Jeff Roberson wrote: It probably still needs some tweaking but it seems to be MUCH better now. New algorithm entirely. nice +20 processes will not run if anything else wants to. idleprio is still not working correctly. bde reports that this causes a 3% perf degradation for buildworld. Isn't nice +20 == idle prio then? My understanding was that idle prio didn't run unless nothing else wanted the CPU which is what you describe nice +20 as doing :) Not quite: - there are 32 different idle priority classes. All of them give infinitely lower (numerically, non-infinitely higher) priority than each other and nice +20. - nice +20 should only only gives infinitely lower priority relative to nice +0 or +1. I hope SCHED_ULE implements this and not what the above says. Otherwise, nice +20 would just be a 33rd idle priority class. Actually, I plan to deprecate rtprio(2) and make nice +31 through +52 correspond to the 32 idle priority classes. Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE nice behavior fixed.
On Thu, 3 Apr 2003, Bruce Evans wrote: On Thu, 3 Apr 2003, Daniel O'Connor wrote: On Wed, 2 Apr 2003 16:24, Jeff Roberson wrote: It probably still needs some tweaking but it seems to be MUCH better now. New algorithm entirely. nice +20 processes will not run if anything else wants to. idleprio is still not working correctly. bde reports that this causes a 3% perf degradation for buildworld. Isn't nice +20 == idle prio then? My understanding was that idle prio didn't run unless nothing else wanted the CPU which is what you describe nice +20 as doing :) Not quite: - there are 32 different idle priority classes. All of them give infinitely lower (numerically, non-infinitely higher) priority than each other and nice +20. - nice +20 should only only gives infinitely lower priority relative to nice +0 or +1. I hope SCHED_ULE implements this and not what the above says. Otherwise, nice +20 would just be a 33rd idle priority class. Actually, I plan to deprecate rtprio(2) and make nice +31 through +52 correspond to the 32 idle priority classes. It implements idle prio as a seperate run queue that is only checked when there is nothing to do, not even nice +20. It is also not hard bound to nice +20. Only ksegs with nice values that are within 20 of the least nice process are given slices. The slices size is inversely proportional to the distance of the ksegs nice from the least nice kseg. It ended up being fairly clean. I do hope you'll look it over some time. Cheers, Jeff ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE nice behavior fixed.
On Wed, Apr 02, 2003 at 07:35:59PM -0500, Jeff Roberson [EMAIL PROTECTED] wrote: Do you know of any problem other than idlepri breakage? I just fixed that. I'm about to get on a plane so I don't have time to benchmark it. If you have a chance I'd love to see how the most recent fixes effect your buildworld time. I still have to microoptimize the code a bit to get rid of switch statements etc, but it all works. Interactivity is still worse under ULE. It's quite noticeable and I tested it on two SMP boxes by running two simple loops in kind of: for ((;;)); do let $((4+4)); done # this is bash specific The loops ran under nice +20. Typing in the xterm is jerky, characters will not show up immediately, but in small bursts. I mean that about three characters typed in will show up immediately, then small pause happens and a burst of characters (which queued up in the pause) will show up. This is annoying. Starting up xterm takes more time as well, but I can live with that. -- Vallo Kallaste ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE nice behavior fixed.
On Thu, 3 Apr 2003, Vallo Kallaste wrote: On Wed, Apr 02, 2003 at 07:35:59PM -0500, Jeff Roberson [EMAIL PROTECTED] wrote: Do you know of any problem other than idlepri breakage? I just fixed that. I'm about to get on a plane so I don't have time to benchmark it. If you have a chance I'd love to see how the most recent fixes effect your buildworld time. I still have to microoptimize the code a bit to get rid of switch statements etc, but it all works. Interactivity is still worse under ULE. It's quite noticeable and I tested it on two SMP boxes by running two simple loops in kind of: for ((;;)); do let $((4+4)); done # this is bash specific The loops ran under nice +20. Typing in the xterm is jerky, characters will not show up immediately, but in small bursts. I mean that about three characters typed in will show up immediately, then small pause happens and a burst of characters (which queued up in the pause) will show up. This is annoying. Starting up xterm takes more time as well, but I can live with that. -- This is strange, I am not seeing any of this behavior. What is the version of your sched_ule.c? I made more changes very recently. Thanks, Jeff ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
