Re: Sleeping in nanos
Re: Sleeping in nanos
- Subject: Re: Sleeping in nanos
- From: Greg <email@hidden>
- Date: Tue, 6 Feb 2007 11:49:14 -0500
Thanks Terry for the info, I asked my question originally under the
(silly) assumption that nanosleep would sleep for the desired amount
after reading the man pages and checking the second argument to it (a
timespec called 'rmtp' in the manpage), which would contain 0 (no
difference) for its tv_nsec variable. I'm not a very big fan of this
nanosleep function now, seeing how on neither linux nor OS X can it
ever sleep for less then 1000 nanoseconds, rendering the function
seemingly useless. It would have been nice had there been a more
descriptive note about this in the man pages of either system (beyond
what's already in there).
- Greg
On Feb 5, 2007, at 5:19 PM, Terry Lambert wrote:
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