Re: load average is 1 when no processes active; etc.
Just for the record, i here have a system cvsupped and built FreeBSD 5.0-CURRENT #0: Sat Sep 9 13:46:17 CEST 2000 which has a constant load average of 1.00 and higher in uptime, top, and systat. The load is already 1.00 or above when the first shell prompt after a boot appears. I've already tried to kill all processes in reach but the load never drops below 1.00 - even in single user mode. Other than this the machine is running fine. hellmuth -- Hellmuth MichaelisTel +49 40 55 97 47-70 HCS Hanseatischer Computerservice GmbHFax +49 40 55 97 47-77 Oldesloer Strasse 97-99 Mail hm [at] hcs.de D-22457 Hamburg WWW http://www.hcs.de To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: load average is 1 when no processes active; etc.
On Mon, 11 Sep 2000, Valentin Nechayev wrote: `top -I' output: ==={ last pid: 811; load averages: 1.01, 0.97, 0.67up 0+00:16:12 23:26:26 This is because the idle process is always running (see "ps lax" outout). Perhaps the bug is that top doesn't show the idle process or other interesting kernel processes like the new interrupt processes. top does nothing to determine LA except getting sysctl "vm.loadavg", isn't it? ("uptime" and "w" says the same avenrun/LA values.) Imho, idle process should not be determined as always running, and idle process state should be fixed. Well, the kernel just doesn't treat it specially, so it gets counted in the load average. I'm not sure if the interrupt and other kernel processes are counted. Since they do useful work, they should be. The idle process does the not so useful work of heating the cpu, since it no longer halts or runs vm_page_zero_idle(). IP Filter: v3.4.9 initialized. Default = pass all, Logging = enabled microuptime() went backwards (1.3891137 - 0.596214) microuptime() went backwards (1.3891137 - 0.596655) ... I get these at boot time on one machine but not on another very similar machine, and often after messing around with ddb. TSC timecounter in all cases. I think they are not a serious problem or related to old timecounter bugs, but they may be related to old bugs setting `switchtime'. What information of my hardware should be reported additionally? None for this problem. It's a general problem. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: load average is 1 when no processes active; etc.
Bruce Evans wrote: On Mon, 11 Sep 2000, Valentin Nechayev wrote: `top -I' output: ==={ last pid: 811; load averages: 1.01, 0.97, 0.67up 0+00:16:12 23:26:26 This is because the idle process is always running (see "ps lax" outout). Perhaps the bug is that top doesn't show the idle process or other interesting kernel processes like the new interrupt processes. top does nothing to determine LA except getting sysctl "vm.loadavg", isn't it? ("uptime" and "w" says the same avenrun/LA values.) Imho, idle process should not be determined as always running, and idle process state should be fixed. Well, the kernel just doesn't treat it specially, so it gets counted in the load average. I'm not sure if the interrupt and other kernel processes are counted. Since they do useful work, they should be. The idle process does the not so useful work of heating the cpu, since it no longer halts or runs vm_page_zero_idle(). BTW, will it be fixed any time soon? Mobile users will certainly like to see idle process halting CPU as it was before. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: load average is 1 when no processes active; etc.
On Mon, 11 Sep 2000, Maxim Sobolev wrote: Bruce Evans wrote: Well, the kernel just doesn't treat it specially, so it gets counted in the load average. I'm not sure if the interrupt and other kernel processes are counted. Since they do useful work, they should be. The idle process does the not so useful work of heating the cpu, since it no longer halts or runs vm_page_zero_idle(). BTW, will it be fixed any time soon? Mobile users will certainly like to see idle process halting CPU as it was before. Not sure. I use this quick fix: --- diff -c2 kern_idle.c~ kern_idle.c *** kern_idle.c~Thu Sep 7 12:32:51 2000 --- kern_idle.c Sun Sep 10 18:06:39 2000 *** *** 40,43 --- 50,55 #endif + extern void (*_hlt_vector)(void); + static void idle_setup(void *dummy); SYSINIT(idle_setup, SI_SUB_SCHED_IDLE, SI_ORDER_FIRST, idle_setup, NULL) *** *** 90,94 --- 102,116 count = 0; + #ifdef __i386__ + disable_intr(); + #endif while (count = 0 procrunnable() == 0) { + #ifdef __i386__ + if (vm_page_zero_idle() != 0) + continue; + (*_hlt_vector)(); + disable_intr(); + continue; + #endif /* * This is a good place to put things to be done in *** *** 99,102 --- 121,127 " for a process"); } + #ifdef __i386__ + enable_intr(); + #endif mtx_enter(sched_lock, MTX_SPIN); --- Add a bogus #include of machine/md_var.h to fix a warning. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: load average is 1 when no processes active; etc.
On Sun, 10 Sep 2000, Valentin Nechayev wrote: `top -I' output: ==={ last pid: 811; load averages: 1.01, 0.97, 0.67up 0+00:16:12 23:26:26 This is because the idle process is always running (see "ps lax" outout). Perhaps the bug is that top doesn't show the idle process or other interesting kernel processes like the new interrupt processes. The same system has another strangeness - `microuptime() went backwards': ==={ /var/run/dmesg.boot ... IPv6 packet filtering initialized, default to accept, logging limited to 100 packets/entry IPsec: Initialized Security Association Processing. ncp_load: [210-213] IP Filter: v3.4.9 initialized. Default = pass all, Logging = enabled microuptime() went backwards (1.3891137 - 0.596214) microuptime() went backwards (1.3891137 - 0.596655) ... I get these at boot time on one machine but not on another very similar machine, and often after messing around with ddb. TSC timecounter in all cases. I think they are not a serious problem or related to old timecounter bugs, but they may be related to old bugs setting `switchtime'. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message