Re: load average is 1 when no processes active; etc.

2000-09-11 Thread Hellmuth Michaelis

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.

2000-09-11 Thread Bruce Evans

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.

2000-09-11 Thread Maxim Sobolev

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.

2000-09-11 Thread Bruce Evans

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.

2000-09-10 Thread Bruce Evans

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