Prev: directories III
Next: 'netstat' and '-f inet' option
From: Rick Jones on 19 Feb 2010 21:18
novickivan(a)gmail.com <novickivan(a)gmail.com> wrote:
> I was wondering if it is valid to use select as a sleep call.

"Back in the day" when the only choices were select() and sleep(),
given sleep() only slept for an integer number of seconds, those who
wanted a short sleep would use select(). And back then one often only
got 10 millisecond resolution - and liked it!-)

With the advent of usleep() and nanosleep() however many years ago
using select() for short sleeps has fallen out of favor.

rick jones
--
Process shall set you free from the need for rational thought.
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
From: Ersek, Laszlo on 19 Feb 2010 21:20
In article <71344f54-8b08-4a9f-a3dd-5870e22acdcf(a)u19g2000prh.googlegroups.com>, "novickivan(a)gmail.com" <novickivan(a)gmail.com> writes:

> I can not sleep for 1 millisecond only.

This may be useful too:

http://www.mjmwired.net/kernel/Documentation/hpet.txt

Cheers,
lacos
From: Alan Curry on 19 Feb 2010 22:20
In article <852ae930-c0f1-4406-9acf-52474583ffa5(a)b9g2000pri.googlegroups.com>,
novickivan(a)gmail.com <novickivan(a)gmail.com> wrote:
|
|Ahhh ok. I am using Suse Enterprise Linux 11. I guess my box is set
|to 250 Hz interval timer.

You can find out like this:

zcat /proc/config.gz | grep HZ

Unless someone's been dumb enough to disable /proc/config.gz

With CONFIG_NO_HZ=y you can get really short sleeps, as the kernel tries to
sleep the time actually requested, instead of rounding it up to the next tick
of a fixed-period timer. You probably won't get 1 usec (a million syscalls in
one second?!) but you may get better resolution than the 100Hz, 250Hz, or
1000Hz timers.

I got this from your program on a CONFIG_NO_HZ machine:

operations took 56 milliseconds
operations took 56 milliseconds

So it appears that each usleep took 56 usec, equivalent to over 17000Hz!

--
Alan Curry
From: Chris Friesen on 20 Feb 2010 00:20
On 02/19/2010 05:29 PM, novickivan(a)gmail.com wrote:

> Does anyone know why there would be any fixed overhead in using select
> that would make it always 4 milliseconds?

As others have said, HZ is probably 250.

You have a couple options:

1) nanosleep() might give finer granularity
2) you could set HZ to 1000
3) you could enable CONFIG_HIGH_RES_TIMERS

Chris
From: Nicolas George on 20 Feb 2010 04:08
Your message explains very well how things work, but it has a technical
mistake I would like to correct for it to be completely accurate.

Jens Thoms Toerring wrote in message <7u8otgFbh9U1(a)mid.uni-berlin.de>:
> Switching between processes takes time. If timeslices are very
> short, a lot of the CPU time will be wasted just for that. Thus
> the length of the timeslice is a compromise between not spending
> too much time on task switching on the one hand and making it
> look for the user as if all processes run at the same time on
> the other. The 4 ms you have seen look like a reasonable value
> for a timeslice - some years ago you normally would have had at
> least 10 ms but with the newer, faster machines, timeslices of
> 4 ms or 1 ms get more and more common. On some systems the length
> of the timeslice can be set when compiling the kernel (e.g. on
> Linux you can select between 100 Hz, 250 Hz and 1 kHz).

You are confusing timeslice and timer interrupt period.

There are two expensive operations: interrupting the process to jump to
kernel space at a timer interrupt is expensive, but scheduling another
process to run is even more expensive. This is especially related to memory
caches: if process B is scheduled to run, then all memory caches kept warm
by process A become useless, and B needs to load all its data from slow RAM.

The timer interrupt (when there is one) provides the kernel with the basic
time scale: not time-related scheduling can be done except at the precision
of the timer interrupt�. But most of the time, the scheduler will just do
nothing and jump back to the current process. For example, if there are two
process A and B requesting CPU time with the same priority, and A has been
running since the previous timer interrupt, the scheduler will probably let
A run for still four or nine timer interrupt periods before preempting it
and running B.

100 / 250 / 1000 Hz is the frequency of the timer interrupt. The duration of
the timeslice is not so simple to predict: modern schedulers use a variable
one. For example, the Linux kernel uses heuristics to distinguish
interactive process from computational process, and gives a smaller
timeslice to niced process.

You can see for yourself using the following perl snippet:

perl -MTime::HiRes="time,sleep" -e '$t=time;
while(1) { $d = time - $t; $t += $d; printf "%.10f\n", $d if $d > 1E-3 }'

Run it alone: it will probably print very few lines. Run it in parallel with
"dd if=/dev/urandom of=/dev/null" (a common way to waste CPU time; run one
per CPU/core if you have a SMP box), and you will see a lot of lines. On my
box, the average output is 22�ms, with a standard deviation of 10�ms. Which
means that the timeslice of the dd process is about 22�ms.

> Going
> beyond that is possible but would make the machine seem to be a
> lot slower without any benefit for most users.

Except for timerless schedulers. The principle is thus: unless some external
event occurs (a packet on the network card raises an interrupt, for
example), when the scheduler is about to run a process, it has exactly as
much information as what it will know when it is invoked by the next timer
interrupt.

So if the next timer interrupt decides "I will not change the running
process. Go.", the current call can predict "the next timer interrupt will
not change the running process". In fact, the current call can predict "I
will not change anything in the next 12�ms". If the hardware is flexible
enough, the scheduler can just disable the next 11 timer interrupts and save
some time and power.

If the hardware allows that and the scheduler is programmed to use it, then
it does not have to have a constant scheduling period: it can decide to
sleep for 42��s once and 420�ms later. It only needs to be careful not to
set up too small intervals too often.

Recent Linux kernels can be compiled with such a timerless scheduler. I do
not know if other mainline kernels have it.


1: Unless the hardware provides other programmable timed interrupt
generators. For example PCs have a RTC device that can generate periodic
interrupts, and the Linux kernel gives access to it through a device node. A
process can thus set it up to be woken at 8�kHz, and will actually run each
time provided its priority is high enough.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: directories III
Next: 'netstat' and '-f inet' option