Re: Sleeping in nanos
Re: Sleeping in nanos
- Subject: Re: Sleeping in nanos
- From: Terry Lambert <email@hidden>
- Date: Mon, 5 Feb 2007 14:19:53 -0800
You already have the answer to the question that caused you to ask
this one, but just to clarify...
No, top doesn't lie, but its truths are perhaps not the same for every
platform.
The top program has a model of "this is the way things are
implemented", and it attempts to collect figures of merit based on its
internal assumptions about system architecture. For any system this
means that you end up with a "libtop" that's platform specific, and
hides the platform dependent bits from the program itself. For a lot
of the numbers that top comes back with, on some platforms, getting
the real numbers and calculating the top numbers requires substantial
effort under the covers.
For the load average, the three numbers that BSD tends to keep (and
which we fake up as part of the context switch management in the Mach
scheduler) and which are reported by "w", "top", and similar programs
are from getloadavg(). This is nominally a weighted moving average,
which is to say that instantaneous load, as measured by number of
items at the top of a ready-to-run queue but not yet scheduled onto a
processor.
You've already gotten answers about the difference in effective timer
resolution in MacOS X vs. Linux (this is obvious, in restrospect,
given the heavy multimedia bent of MacOS X, and the difference in the
"fairness" guarantees in the scheduler for multiple threads) that
mostly account for the difference you are observing. I'd just add
that if a timer fires sooner rather than being rounded up to some
boundary, the instantaneous numbers of things in a read-to-run state
are going to be exaggerated upward by the ratio of the diffference in
timer resolution. Put another way... if my timer fires at an exact
time instead of a rounded time, then for a very small interval
relative to system call overhead, I'm going to see a process on the
read-to-run queue a lot more frequently.
As others have pointed out, this makes the idea of instantaneous load
average not very useful for this type of statistics gathering, and you
are much better off with "time" and similar commands that use
getrusage() for accumulated child process resource usage as accounted
by the scheduler directly.
-- Terry
On Feb 2, 2007, at 11:32 PM, Greg wrote:
I'm simply using "top" on both systems, one is a MacBook Pro C2D,
the other is some fast AMD processor. Are you saying that "top"
lies? There's one thing that doesn't lie for sure, and that is the
fans on my MBP which will become quite audible.
- Greg
On Feb 3, 2007, at 2:05 AM, Terry Lambert wrote:
How is it being measured on Linux?
Is it being done as a weighted moving average on scheduler
transitions, or is it based on sleeping in the idle loop, or what?
Or is a system considered "loaded" only when there are processes on
a "ready to run" queue, waiting assignment to a CPU? If the
latter, is it loaded 100% any time the value waiting for a CPU is
non-zero, or is the load based on number of "runnable" vs. "total",
and/or does it include the currently running processes as part of
the load, etc.?
Different approaches to measuring will give different answers, and
almost all systems
If your answer is coming from "top" vs. "w" vs. "uptime" vs.
getloadavg(), you are going to get a subjective measurement.
If this is an Intel system (i.e. you are comparing the same machine
running MacOS X with one running Linux), my suggestion is to use
the TSC instruction to get cycle counts, and compare those instead
of trying to compare fictitious "load average" numbers that are
likely calculated in different ways.
-- Terry
On Feb 2, 2007, at 8:38 PM, Greg wrote:
So then why do I barely see 1% CPU utilization on linux?
- Greg
On Feb 2, 2007, at 11:05 PM, Ed Wynne wrote:
From: Greg <email@hidden>
Date: February 2, 2007 10:28:08 PM EST
To: Darwin Kernel <email@hidden>
Subject: Sleeping in nanos
Is there a way on OS X to sleep for 1000 nanoseconds without
causing 65% CPU usage? I have tried nanosleep and clock_sleep
(using TIME_RELATIVE and a REALTIME_CLOCK), and both seem to
simply cause a busy loop.
Assuming an instruction takes one cycle (some do, lots don't) and
a 2Ghz CPU, each instruction will take .5ns. That means the CPU
can run 2000 instructions, at most, while your sleeping for 1us.
Given that any kind of sleep function will be a syscall into the
kernel and invoke the scheduler, I'd be willing to bet it takes a
lot more than 2000 instructions just to put yourself to sleep and
then wake back up. Your 65% CPU usage is probably indicative of
this. It is taking longer to setup and recover from sleep than
your spending sleeping.
-Ed
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden