Re: 100% system time? (SMPng on UP system)
On 16 Sep, John Baldwin wrote: None of the CPU states from vmmeter are close to accurate on UP x86 systems at the moment because statclock() doesn't have a valid stack frame to work with. SMP is slightly more accurate as we get all the stats on the other CPU's correct. This is on the todo list to fix, but it is merely cosmetic, so it is farther down on the list than, say, finishing up threading interrupts on the alpha. :) It wasn't mentioned in the known bugs list, so I thought it wasn't known. BTW: Good work, keep going on. Bye, Alexander. -- Intel: where Quality is job number 0.9998782345! http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 100% system time? (SMPng on UP system)
On 17 Sep, Bruce Evans wrote:
dnetc runns with idprio 31, system cvsupped around Sep 16, 11 CEST from
a german mirror (it contains the idle fixes: src/sys/kern/kern_idle.c,v
1.4), complete build{world,kernel}.
---snip---
last pid: 1666; load averages: 1.10, 1.11, 1.03up 0+00:51:21 16:54:14
Perhaps it really is a system process :-[. idprio on a pure cpu hog prevents
other user processes from running like a system process might do:
idprio 31 sh -c "while :; do :; done"
System processes actually hang the entire system until they complete:
Are you mixing idprio with rtprio or did I not understand what you
explain?
Bye,
Alexander.
--
There's no place like ~
http://www.Leidinger.net Alexander @ Leidinger.net
GPG fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: 100% system time? (SMPng on UP system)
On Sun, 17 Sep 2000, Alexander Leidinger wrote:
On 17 Sep, Bruce Evans wrote:
dnetc runns with idprio 31, system cvsupped around Sep 16, 11 CEST from
a german mirror (it contains the idle fixes: src/sys/kern/kern_idle.c,v
1.4), complete build{world,kernel}.
---snip---
last pid: 1666; load averages: 1.10, 1.11, 1.03up 0+00:51:21 16:54:14
Perhaps it really is a system process :-[. idprio on a pure cpu hog prevents
other user processes from running like a system process might do:
idprio 31 sh -c "while :; do :; done"
System processes actually hang the entire system until they complete:
Are you mixing idprio with rtprio or did I not understand what you
explain?
You didn't understand :-). Try the example. It only uses idprio.
rtprio certainly causes system hangs, and the supergiant lock may
increase the problem. Before SMPng, rtprio processes prevented all
non-rtprio processes including important daemons (and I think even
kernel processes) from running. Starting an infinite loop at rtprio
while remotely logged in was fatal because a ^C (character, not signal)
to kill the process couldn't be delivered.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: 100% system time? (SMPng on UP system)
In message [EMAIL PROTECTED], Bruce Ev ans writes: Perhaps it really is a system process :-[. idprio on a pure cpu hog prevents other user processes from running like a system process might do: idprio 31 sh -c "while :; do :; done" System processes actually hang the entire system until they complete: Are you mixing idprio with rtprio or did I not understand what you explain? You didn't understand :-). Try the example. It only uses idprio. rtprio certainly causes system hangs, and the supergiant lock may increase the problem. Before SMPng, rtprio processes prevented all non-rtprio processes including important daemons (and I think even kernel processes) from running. Starting an infinite loop at rtprio while remotely logged in was fatal because a ^C (character, not signal) to kill the process couldn't be delivered. I can confirm this one, ntpd has for a long time pointlessly raised it's priority to the absolute maximum, and if during debugging it went into a spin it would freeze the system. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 100% system time? (SMPng on UP system)
On 18 Sep, Bruce Evans wrote:
dnetc runns with idprio 31, system cvsupped around Sep 16, 11 CEST from
a german mirror (it contains the idle fixes: src/sys/kern/kern_idle.c,v
1.4), complete build{world,kernel}.
---snip---
last pid: 1666; load averages: 1.10, 1.11, 1.03up 0+00:51:21 16:54:14
Perhaps it really is a system process :-[. idprio on a pure cpu hog prevents
other user processes from running like a system process might do:
idprio 31 sh -c "while :; do :; done"
System processes actually hang the entire system until they complete:
Are you mixing idprio with rtprio or did I not understand what you
explain?
You didn't understand :-). Try the example. It only uses idprio.
I have dnetc still running with idprio 31 and it didn't hang the entire
system (I'm able to write this mail and compiling a port in the
background while dnetc is running).
As I understand this:
- The man-page of idprio says it allows processes only to run if the
system is idle.
- You say, in my case (dnetc is a cpu hog, isn't it?) idprio prevents
other processes from running (the opposide of what I want).
- I say, dnetc is running in the background with idprio 31 and I'm able
to do usefull work while it is running.
Confused,
Alexander.
--
Reboot America.
http://www.Leidinger.net Alexander @ Leidinger.net
GPG fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: 100% system time? (SMPng on UP system)
On Sun, 17 Sep 2000, Alexander Leidinger wrote:
On 18 Sep, Bruce Evans wrote:
dnetc runns with idprio 31, system cvsupped around Sep 16, 11 CEST from
a german mirror (it contains the idle fixes: src/sys/kern/kern_idle.c,v
1.4), complete build{world,kernel}.
---snip---
last pid: 1666; load averages: 1.10, 1.11, 1.03up 0+00:51:21 16:54:14
Perhaps it really is a system process :-[. idprio on a pure cpu hog prevents
other user processes from running like a system process might do:
idprio 31 sh -c "while :; do :; done"
System processes actually hang the entire system until they complete:
Are you mixing idprio with rtprio or did I not understand what you
explain?
You didn't understand :-). Try the example. It only uses idprio.
I have dnetc still running with idprio 31 and it didn't hang the entire
system (I'm able to write this mail and compiling a port in the
background while dnetc is running).
dnetc presumably blocks occasionally, giving other processes a chance to
run.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: 100% system time? (SMPng on UP system)
On 18 Sep, Bruce Evans wrote: dnetc presumably blocks occasionally, giving other processes a chance to run. I've started dnetc without idprio (with build in "nice"), it also displays 100% system. And with a closer look (stopped dnetc): 0% user, 0% nice... ? ---snip--- last pid: 36437; load averages: 0.68, 1.44, 1.41up 0+06:53:18 17:23:03 73 processes: 1 running, 70 sleeping, 1 stopped, 1 zombie CPU states: 0.0% user, 0.0% nice, 30.2% system, 5.2% interrupt, 64.6% idle Mem: 63M Active, 13M Inact, 33M Wired, 5644K Cache, 22M Buf, 6580K Free Swap: 266M Total, 43M Used, 223M Free, 15% Inuse, 8K In kill PID USERNAME PRI NICE SIZERES STATETIME WCPUCPU COMMAND 35709 netchild 2 0 10956K 6736K poll 1:48 8.94% 8.94% xmms 732 netchild 2 0 3224K 1048K select 0:05 5.81% 5.81% xterm 658 root 2 0 80016K 33516K select 10:48 4.98% 4.98% XF86_SVGA 457 netchild -6 0 2856K 512K pcmwr0:46 2.49% 2.49% esd ---snip--- Bye, Alexander. -- I believe the technical term is "Oops!" http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
100% system time? (SMPng on UP system)
Hi,
dnetc runns with idprio 31, system cvsupped around Sep 16, 11 CEST from
a german mirror (it contains the idle fixes: src/sys/kern/kern_idle.c,v
1.4), complete build{world,kernel}.
---snip---
last pid: 1666; load averages: 1.10, 1.11, 1.03up 0+00:51:21 16:54:14
71 processes: 3 running, 67 sleeping, 1 zombie
CPU states: 0.0% user, 0.0% nice, 100% system, 0.0% interrupt, 0.0% idle
Mem: 61M Active, 16M Inact, 27M Wired, 6944K Cache, 22M Buf, 10M Free
Swap: 266M Total, 266M Free
kill
PID USERNAME PRI NICE SIZERES STATETIME WCPUCPU COMMAND
355 nobody48 52 772K 416K RUN 40:16 91.11% 91.11% dnetc
1209 root 2 0 65448K 28492K select 1:05 2.25% 2.25% XF86_SVGA
---snip---
and with the idprio'd dnetc stopped:
---snip---
last pid: 1670; load averages: 0.80, 1.05, 1.02up 0+00:52:43 16:55:36
72 processes: 2 running, 68 sleeping, 1 stopped, 1 zombie
CPU states: 0.0% user, 0.0% nice, 4.3% system, 0.0% interrupt, 95.7% idle
Mem: 62M Active, 16M Inact, 27M Wired, 6944K Cache, 22M Buf, 8568K Free
Swap: 266M Total, 266M Free
kill
PID USERNAME PRI NICE SIZERES STATETIME WCPUCPU COMMAND
355 nobody48 52 772K 416K STOP41:09 38.38% 38.38% dnetc
1209 root 2 0 66576K 29624K select 1:09 1.71% 1.71% XF86_SVGA
---snip---
Bye,
Alexander.
--
Speak softly and carry a cellular phone.
http://www.Leidinger.net Alexander @ Leidinger.net
GPG fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: 100% system time? (SMPng on UP system)
Alexander Leidinger wrote:
Hi,
dnetc runns with idprio 31, system cvsupped around Sep 16, 11 CEST from
a german mirror (it contains the idle fixes: src/sys/kern/kern_idle.c,v
1.4), complete build{world,kernel}.
None of the CPU states from vmmeter are close to accurate on UP x86
systems at the moment because statclock() doesn't have a valid stack
frame to work with. SMP is slightly more accurate as we get all the
stats on the other CPU's correct. This is on the todo list to fix,
but it is merely cosmetic, so it is farther down on the list than, say,
finishing up threading interrupts on the alpha. :)
--
John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: 100% system time? (SMPng on UP system)
On Sat, 16 Sep 2000, Alexander Leidinger wrote:
dnetc runns with idprio 31, system cvsupped around Sep 16, 11 CEST from
a german mirror (it contains the idle fixes: src/sys/kern/kern_idle.c,v
1.4), complete build{world,kernel}.
---snip---
last pid: 1666; load averages: 1.10, 1.11, 1.03up 0+00:51:21 16:54:14
Perhaps it really is a system process :-[. idprio on a pure cpu hog prevents
other user processes from running like a system process might do:
idprio 31 sh -c "while :; do :; done"
System processes actually hang the entire system until they complete:
dd if=/dev/random of=/dev/null bs=10m count=1
This takes 32 seconds on a Celeron 366 overclocked to 523, during
which time no other processes, including interrupt tasks, can run.
This is because the supergiant lock prevents context switching while
the i/o is being done. There is nothing special about /dev/random
here except that it has a low transfer rate.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
