Re: Change top's notion of idle processes / threads
John Baldwin j...@freebsd.org wrote: Yes, I actually started by sorting on the raw delta and ended up going back and fixing pctcpu instead. However, there is a problem in this case which is that you still want to fall back to ki_pctcpu if you don't have a valid previous delta to compare against. It's a lot simpler to just fixup ki_pctcpu and not have to go change the sorting code explicitly. :( I actually started out having a function that returned a double for the pctcpu, but that would mean recalculating the raw pctcpu many, many times during the sort. Just updating ki_pctcpu once per each process/thread per fetch scales a bit better. I could perhaps use an array to cache raw percentages as doubles. Sorry for the delay in getting back to you. Thanks for the explanation - it makes sense. (I mean that I understand what you are saying - not that I'm somehow misguidingly attempting to give my approval!) I can see how improving the granularity of pctcpu would be a much cleaner solution - I just didn't know which solution was easier (and after finally looking at the source, I still didn't know :-) ) Ok, try people.freebsd.org/~jhb/patches/top_pctcpu2.patch Brilliant. I wasn't able to get contradictory results this time - however much I tried! I have a few server processes that are constantly active (receiving many requests per second) but use a well written piece of code that handles them efficiently. With the stock 10-stable, and with the previous patch, they always registered as 0.00% cpu (and consequently were not shown at all in idle-only mode on 10-stable) (I'm not doubting the general stats - I reconfigured one of them earier today, and in 7 hours it's clocked up 2.2 seconds) With the latest patch, they now report as 0:01% which not only corrects the sort order, but makes more sense than 0.00% for a non-idle process, even if the value before rounded is closer to 0.00 than 0.01 Other processes which are generally in tick-over, but also idle much of the time now pop in and out of view as expected, and sorted as expected. not sure what you've done I'm guessing without looking at the patch code (lazy persons approach) that you have either improved the accuracy of pctcpu, or you now round any non-idle cpu usage below 0.00 up to 0.01 Whatever It works. The old top was mainly handy for watching heavy usage processes (don't get me wrong, it's invaluable for that). The new top is now also producing results similar to what I'd previously had to manually extrapolate from a series of repeated targetted 'ps' commands. I'll let you know if I notice anything weird, or if I manage to break anything :-) but I'm confident that this won't happen. A BIG thumbs up for this... Push into current, then MFC now! :-) Cheers, Jamie ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Change top's notion of idle processes / threads
On May 28, 2014, at 9:54, John Baldwin j...@freebsd.org wrote: Yes, I actually started by sorting on the raw delta and ended up going back and fixing pctcpu instead. However, there is a problem in this case which is that you still want to fall back to ki_pctcpu if you don't have a valid previous delta to compare against. It's a lot simpler to just fixup ki_pctcpu and not have to go change the sorting code explicitly. :( I actually started out having a function that returned a double for the pctcpu, but that would mean recalculating the raw pctcpu many, many times during the sort. Just updating ki_pctcpu once per each process/thread per fetch scales a bit better. I could perhaps use an array to cache raw percentages as doubles. Ok, try people.freebsd.org/~jhb/patches/top_pctcpu2.patch Hey, all the 0.00% processes on my server now show up in top with measurable usage. Nice. (They're all between 0.3% and 0.9%) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Change top's notion of idle processes / threads
John, the changes are good. The 'trickling' but still not idle processes now show up as they should. However, it has exposed one quirk in the display: Sorting is done by WCPU followed by total processor time. Processes which aren't idle (but are using so little cpu it shows as 0.00%) show below processes which are truely idle, but have totaled more processor time overall. This is more noticable with your new patch, as toggling between idle-only and full now shows processes appearing higher in the list than some which only appear in the non-idle view! Ideally, processes where cpu is virtually 0.00% but really a smidgen higher should be display higher. I realise the pctcpu granularity is at fault here. Basically, what I'm saying is that truely idle processes should appear below other processes reporting 0.00% cpu. In other words, what I'm asking is: shouldn't the cpu sort priority not simply be keyed on 'ki_pctcpu', but on a primary key based on if cur-ki_runtime == old-ki_runtime ? followed by secondary key ki_pctcpu. Or even easier, shouldn't simply sorting on (cur-ki_runtime - old-ki_runtime) suffice? Is this a valid point, and if it is, is it practical, and/or easy enough to achieve? I'll even have a stab at it myself tomorrow, after hopefully getting some sleep (32 hours without sleep - sorry for incoherency - insomnia is a PITA) Cheers, Jamie ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Change top's notion of idle processes / threads
On Sunday, May 25, 2014 3:11:05 am Kubilay Kocak wrote: On 24/05/2014 7:22 AM, Allan Jude wrote: On 2014-05-23 16:05, John Baldwin wrote: Right now, when top is set to not display idle processes or threads, it only displays processes or threads that are currently in a runnable state or have a non-zero %cpu. However, our %cpu is quite imprecise. I have patch to change top to instead compare the thread or processes runtime (ki_runtime in kinfo_proc) against the runtime of the thread or process the last time data was fetched. In essence, top will consider any thread that has run on a CPU since the last update as non-idle. The end result is that mostly-idle threads and processes will now be visible in top's idle display. Personally, I find this more useful (and find the current implementation completely useless). The patch is at http://people.freebsd.org/~jhb/patches/top_idle.patch Comments? I think this makes good sense. I would definitely prefer it. Would it make sense to maybe preserve the old behaviour behind a command line flag? And an update to top(8) reflecting the algo :) I know these little esoteric things could always do with more obvious breadcrumbs (like load average calcs, etc) for our future selves and others. As Ed noted, the manpage is already fairly vague here. Given the responses so far, everyone finds the new behavior more intuitive than the old one. +1 on the behavior change, not sure about retaining the old under a flag. Who might benefit from it? How do other OS top implementations calculate their idle? If there's other examples out there with the same (current) algo, then retaining compat might be worth it, such as for newly converted users This isn't really that big of a behavior change in practice. It is just using a more precise measurement for the current 'ki_pctcpu != 0' test that is already there. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Change top's notion of idle processes / threads
On Wednesday, May 28, 2014 8:20:35 am Jamie Landeg-Jones wrote: John, the changes are good. The 'trickling' but still not idle processes now show up as they should. However, it has exposed one quirk in the display: Sorting is done by WCPU followed by total processor time. Processes which aren't idle (but are using so little cpu it shows as 0.00%) show below processes which are truely idle, but have totaled more processor time overall. This is more noticable with your new patch, as toggling between idle-only and full now shows processes appearing higher in the list than some which only appear in the non-idle view! Ideally, processes where cpu is virtually 0.00% but really a smidgen higher should be display higher. I realise the pctcpu granularity is at fault here. Basically, what I'm saying is that truely idle processes should appear below other processes reporting 0.00% cpu. In other words, what I'm asking is: shouldn't the cpu sort priority not simply be keyed on 'ki_pctcpu', but on a primary key based on if cur-ki_runtime == old-ki_runtime ? followed by secondary key ki_pctcpu. Or even easier, shouldn't simply sorting on (cur-ki_runtime - old-ki_runtime) suffice? Is this a valid point, and if it is, is it practical, and/or easy enough to achieve? I'll even have a stab at it myself tomorrow, after hopefully getting some sleep (32 hours without sleep - sorry for incoherency - insomnia is a PITA) Yes, I actually started by sorting on the raw delta and ended up going back and fixing pctcpu instead. However, there is a problem in this case which is that you still want to fall back to ki_pctcpu if you don't have a valid previous delta to compare against. It's a lot simpler to just fixup ki_pctcpu and not have to go change the sorting code explicitly. :( I actually started out having a function that returned a double for the pctcpu, but that would mean recalculating the raw pctcpu many, many times during the sort. Just updating ki_pctcpu once per each process/thread per fetch scales a bit better. I could perhaps use an array to cache raw percentages as doubles. Ok, try people.freebsd.org/~jhb/patches/top_pctcpu2.patch -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Change top's notion of idle processes / threads
On Friday, May 23, 2014 4:39:39 pm Poul-Henning Kamp wrote: In message 201405231605.26312@freebsd.org, John Baldwin writes: In essence, top will consider any thread that has run on a CPU since the last update as non-idle. Sounds a lot more usable than the current heuristic. Wouldn't ki_rusage.ru_n[i]vcsw be more correct than ki_runtime ? I went ahead and checked for both. In theory we might fix our scheduler one day to notice when a CPU is dedicated to a single thread not bother with doing silly context switches back to itself in which case only ki_runtime would change. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Change top's notion of idle processes / threads
On 26 May 2014 11:51, Ed Maste ema...@freebsd.org wrote: The change in the patch is good, the new behaviour is much more usable. Note that we don't currently define idle in top(8); for this change maybe we should just state that non-idle processes may report 0% CPU due to rounding. That said, I've discovered an issue with the change after using it a bit more, when using -I on the command line. (Previously I only tried it by pressing I in interactive mode.) With the change top -I lists all processes at first (which is a little annoying), but it renders -I ineffective when used with -b (batch mode). What do you think about this additional change, so that we use the previous 0% idleness test for the first iteration of the list: if (oldp == NULL) - return (pp-ki_runtime != 0); + return (pp-ki_pctcpu != 0); -Ed ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Change top's notion of idle processes / threads
On Tuesday, May 27, 2014 10:43:56 am Ed Maste wrote: On 26 May 2014 11:51, Ed Maste ema...@freebsd.org wrote: The change in the patch is good, the new behaviour is much more usable. Note that we don't currently define idle in top(8); for this change maybe we should just state that non-idle processes may report 0% CPU due to rounding. That said, I've discovered an issue with the change after using it a bit more, when using -I on the command line. (Previously I only tried it by pressing I in interactive mode.) With the change top -I lists all processes at first (which is a little annoying), but it renders -I ineffective when used with -b (batch mode). What do you think about this additional change, so that we use the previous 0% idleness test for the first iteration of the list: if (oldp == NULL) - return (pp-ki_runtime != 0); + return (pp-ki_pctcpu != 0); Not a bad idea. I have another change that also reworks how ki_pctcpu is calculated. Namely, if this is a subsequent update and we have the kinfo_proc from the previous update (or if the process/thread in question is a newborn since the previous update) this patch uses delta(ki_runtime) / delta(CLOCK_UPTIME) to calculate a true %CPU across the interval. As opposed to the scheduler-calculated %CPU which has a long delay function, this causes the %CPU column in top to reflect changes in behavior much more quickly and to also give a more accurate view of mostly-idle processes and threads. However, in actual use it seems to have some jitter as I can't atomically grab a CLOCK_UPTIME value with the kern.proc sysctl info. As a result, I see occasional rounding errors where a 'while (1)' loop can oscillate between 98 and 102% CPU usage for example. Still, if you start a while (1) loop, it jumps to the top of the list much quicker (and falls off as soon as you pause it). For the initial fetch (and for batch mode) it uses the scheduler- calculated value still. I also adopted phk@'s suggestion of counting changes in ru_nvcsw/ru_nivcsw as evidence of running. http://people.freebsd.org/~jhb/patches/top_pctcpu.patch -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Change top's notion of idle processes / threads
On 25 May 2014 03:11, Kubilay Kocak ko...@freebsd.org wrote: On 24/05/2014 7:22 AM, Allan Jude wrote: I think this makes good sense. I would definitely prefer it. Would it make sense to maybe preserve the old behaviour behind a command line flag? And an update to top(8) reflecting the algo :)I know these little esoteric things could always do with more obvious breadcrumbs (like load average calcs, etc) for our future selves and others. +1 on the behavior change, not sure about retaining the old under a flag. Who might benefit from it? How do other OS top implementations calculate their idle? If there's other examples out there with the same (current) algo, then retaining compat might be worth it, such as for newly converted users The change in the patch is good, the new behaviour is much more usable. Note that we don't currently define idle in top(8); for this change maybe we should just state that non-idle processes may report 0% CPU due to rounding. A flag for the old behaviour seems like a bad idea. We already have an adequate supply of knobs and modes and options that don't provide real value, and just add work for our users to determine if they should be set or not. -Ed ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Change top's notion of idle processes / threads
On 24/05/2014 7:22 AM, Allan Jude wrote: On 2014-05-23 16:05, John Baldwin wrote: Right now, when top is set to not display idle processes or threads, it only displays processes or threads that are currently in a runnable state or have a non-zero %cpu. However, our %cpu is quite imprecise. I have patch to change top to instead compare the thread or processes runtime (ki_runtime in kinfo_proc) against the runtime of the thread or process the last time data was fetched. In essence, top will consider any thread that has run on a CPU since the last update as non-idle. The end result is that mostly-idle threads and processes will now be visible in top's idle display. Personally, I find this more useful (and find the current implementation completely useless). The patch is at http://people.freebsd.org/~jhb/patches/top_idle.patch Comments? I think this makes good sense. I would definitely prefer it. Would it make sense to maybe preserve the old behaviour behind a command line flag? And an update to top(8) reflecting the algo :) I know these little esoteric things could always do with more obvious breadcrumbs (like load average calcs, etc) for our future selves and others. +1 on the behavior change, not sure about retaining the old under a flag. Who might benefit from it? How do other OS top implementations calculate their idle? If there's other examples out there with the same (current) algo, then retaining compat might be worth it, such as for newly converted users -- Koobs ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Change top's notion of idle processes / threads
Right now, when top is set to not display idle processes or threads, it only displays processes or threads that are currently in a runnable state or have a non-zero %cpu. However, our %cpu is quite imprecise. I have patch to change top to instead compare the thread or processes runtime (ki_runtime in kinfo_proc) against the runtime of the thread or process the last time data was fetched. In essence, top will consider any thread that has run on a CPU since the last update as non-idle. The end result is that mostly-idle threads and processes will now be visible in top's idle display. Personally, I find this more useful (and find the current implementation completely useless). The patch is at http://people.freebsd.org/~jhb/patches/top_idle.patch Comments? -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Change top's notion of idle processes / threads
On 05/23/2014 15:05, John Baldwin wrote: Right now, when top is set to not display idle processes or threads, it only displays processes or threads that are currently in a runnable state or have a non-zero %cpu. However, our %cpu is quite imprecise. I have patch to change top to instead compare the thread or processes runtime (ki_runtime in kinfo_proc) against the runtime of the thread or process the last time data was fetched. In essence, top will consider any thread that has run on a CPU since the last update as non-idle. The end result is that mostly-idle threads and processes will now be visible in top's idle display. Personally, I find this more useful (and find the current implementation completely useless). The patch is at http://people.freebsd.org/~jhb/patches/top_idle.patch Comments? I think I would much prefer the behavior with your patch. Eric ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Change top's notion of idle processes / threads
In message 201405231605.26312@freebsd.org, John Baldwin writes: In essence, top will consider any thread that has run on a CPU since the last update as non-idle. Sounds a lot more usable than the current heuristic. Wouldn't ki_rusage.ru_n[i]vcsw be more correct than ki_runtime ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Change top's notion of idle processes / threads
On 2014-05-23 16:05, John Baldwin wrote: Right now, when top is set to not display idle processes or threads, it only displays processes or threads that are currently in a runnable state or have a non-zero %cpu. However, our %cpu is quite imprecise. I have patch to change top to instead compare the thread or processes runtime (ki_runtime in kinfo_proc) against the runtime of the thread or process the last time data was fetched. In essence, top will consider any thread that has run on a CPU since the last update as non-idle. The end result is that mostly-idle threads and processes will now be visible in top's idle display. Personally, I find this more useful (and find the current implementation completely useless). The patch is at http://people.freebsd.org/~jhb/patches/top_idle.patch Comments? I think this makes good sense. I would definitely prefer it. Would it make sense to maybe preserve the old behaviour behind a command line flag? -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: Change top's notion of idle processes / threads
On Friday, May 23, 2014 4:39:39 pm Poul-Henning Kamp wrote: In message 201405231605.26312@freebsd.org, John Baldwin writes: In essence, top will consider any thread that has run on a CPU since the last update as non-idle. Sounds a lot more usable than the current heuristic. Wouldn't ki_rusage.ru_n[i]vcsw be more correct than ki_runtime ? Hmmm, possibly. ki_runtime in the kernel is basically TSC counts and gets updated on each context switch. OTOH, I think the exported version only has microsecond granularity which is probably too small. :( I can try your suggestion. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
