select takes too much time

select takes too much time

[Ram Gupta]

I am using select with a timeout value of 90 ms. But for some reason
occasionally  it comes out of select after more than one second . I
checked the man page but it does not help in concluding if this is ok
or not. Is this expected  or it is a bug. Most of this time is
consumed in   schedule_timeout . I am using 2.5.45 kernel but I
believe the same would  be the true for the latest kernel too. Any
thoughts or suggestion are welcome.

Thanks
Ram Gupta

Re: select takes too much time

[Andreas Mohr]

Hi,

On Thu, Apr 13, 2006 at 10:01:04AM -0500, Ram Gupta wrote:
> I am using select with a timeout value of 90 ms. But for some reason
> occasionally  it comes out of select after more than one second . I
> checked the man page but it does not help in concluding if this is ok
> or not. Is this expected  or it is a bug. Most of this time is
> consumed in   schedule_timeout . I am using 2.5.45 kernel but I
> believe the same would  be the true for the latest kernel too. Any
> thoughts or suggestion are welcome.

AFAIK (I'm not an absolute expert on this, but it should be about correct):
Any user of select() competes with all other processes on the system
for the attention of the scheduler. If there are always runnable tasks
available with a higher priority than the select() user, then it's easily
imaginable that those tasks get woken up and/or will be kept running first.
The timeout value given to select() thus states the *minimum* time that
the process will continue after if the timeout has been fully taken (i.e.
no event occurred).
The man page of select() is a bit inaccurate in saying that "it will return
immediately". Well, it will *try to* return ASAP once it has decided to
return. BUT the scheduler will *always* have ultimate authority upon when
*exactly* this process will be allowed to continue.

Now if you have issues with select() taking too long, then I'd say tough
luck, that's life, other processes seem more important than your select()
user, but OTOH it could mean that our scheduler design is not assigning
enough importance to processes waiting on a select() and becoming runnable
again (however I strongly doubt that, since there has gone a LOT of work into
proper scheduler design in Linux).

Or, to put it differently, select() doesn't have realtime guarantees, i.e.
there's no way for you to boldly assume that once select() times out
your process will continue to run instantly within microseconds.

Finally, *any* scheduling timeout on a system should be taken for granted
as a *minimum* guarantee only. This is also why looped msleep()s in
Linux drivers should very often be coupled with a jiffies timeout condition
just in case the system is so extremely busy that each msleep(1) takes up
3 seconds, thus letting a 300 times 1ms loop end up as 900 seconds instead...

Whoa, way too many words for answering such a basic issue...
(but this problem being so basic it probably cannot be explained too often)

Oh, and another related word of advice: when doing thread programming,
always synchronize parallel threads by letting them *block* on each others
status instead of letting the peer thread busy-loop for the other thread to
finish its work. Good schedulers *will* punish busy-looping and honour
proper blocking on a condition, so your software will suffer a lot when
doing too much busy-looping or semi-busy-looping (too many useless wakeups).

Andreas Mohr

-- 
Please consider not buying any HDTV hardware! (extremely anti-consumer)
Bitte kaufen Sie besser keinerlei HDTV-Geräte! (extrem verbraucherfeindlich)
Infos:
http://www.hdboycott.com   http://www.eff.org/IP/DRM/   http://bluraysucks.com

Re: select takes too much time

[linux-os (Dick Johnson)]

On Thu, 13 Apr 2006, Ram Gupta wrote:

> I am using select with a timeout value of 90 ms. But for some reason
> occasionally  it comes out of select after more than one second . I
> checked the man page but it does not help in concluding if this is ok
> or not. Is this expected  or it is a bug. Most of this time is
> consumed in   schedule_timeout . I am using 2.5.45 kernel but I
> believe the same would  be the true for the latest kernel too. Any
> thoughts or suggestion are welcome.
>
> Thanks
> Ram Gupta

This may point out a problem with a driver that is polling
inside a spin-lock or other places where interrupts are disabled.
It is unlikely that select() or poll() are at fault. I have a
server that takes high-speed DAS data and sends it over the
network as UDP packets. The server sleeps in poll() until data
are ready, then wakes up and sends the data. This happens 4,000
times per second and has been tested to 10,000 times per second.
The HZ value on that server is 1024. So, poll() and select()
can be fast in response to a 'wake_up_interruptible()' inside
a driver. They should be equally fast to a normal timeout.

Make sure that your 'struct timeval' is initialized prior to every
call to select(). Linux writes remaining time back into that
structure! Also make sure you are using the right structure,
'struct timeval', not 'struct timespec'!

Cheers,
Dick Johnson
Penguin : Linux version 2.6.15.4 on an i686 machine (5589.54 BogoMips).
Warning : 98.36% of all statistics are fiction, book release in April.
_
\x1a\x04

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: select takes too much time

[Ram Gupta]

On 4/13/06, Andreas Mohr <andi@rhlx01.fht-esslingen.de> wrote:
> Hi,
>


>
> Now if you have issues with select() taking too long, then I'd say tough
> luck, that's life, other processes seem more important than y
>
> Or, to put it differently, select() doesn't have realtime guarantees, i.e.
> there's no way for you to boldly assume that once select() times out
> your process will continue to run instantly within microseconds.

I was not expecting it to run instantly within microseconds but 1
second seemed to me too much

Re: select takes too much time

[Jan Knutar]

On Thursday 13 April 2006 18:01, Ram Gupta wrote:
> I am using select with a timeout value of 90 ms. But for some reason
> occasionally  it comes out of select after more than one second .

I have a memory-starved prosignia that sometimes needs up to
10 seconds :)
Though that includes bringing in the relevant code page of the userspace
application too, and that page probably gets discarded after doing the
syscall, or similar.
It's all allright though, it gets served eventually.

> I 
> checked the man page but it does not help in concluding if this is ok
> or not.

The documentation doesn't impose or guarantee any minimum performance,
as far as I know.

Re: select takes too much time

[Michal Schmidt]

Ram Gupta wrote:
> I am using 2.5.45 kernel but I believe the same would  be the true
> for the latest kernel too.

Are you just assuming this, or did you actually try a recent kernel?

Michal

Re: select takes too much time

[Ram Gupta]

On 4/13/06, Michal Schmidt <xschmi00@stud.feec.vutbr.cz> wrote:
> Ram Gupta wrote:
> > I am using 2.5.45 kernel but I believe the same would  be the true
> > for the latest kernel too.
>
> Are you just assuming this, or did you actually try a recent kernel?
>
> Michal
>

I didn't get a chance to try it on a recent kernel yet but I believe
it to be so though I may be  wrong

Ram

Re: select takes too much time

[linux-os (Dick Johnson)]

On Thu, 13 Apr 2006, Ram Gupta wrote:

> On 4/13/06, Michal Schmidt <xschmi00@stud.feec.vutbr.cz> wrote:
>> Ram Gupta wrote:
>>> I am using 2.5.45 kernel but I believe the same would  be the true
>>> for the latest kernel too.
>>
>> Are you just assuming this, or did you actually try a recent kernel?
>>
>> Michal
>>
>
> I didn't get a chance to try it on a recent kernel yet but I believe
> it to be so though I may be  wrong
>
> Ram
> -

Simple program here shows that you may be right! In principle,
I should be able to multiply the loop-count by 10 and divide
the sleep time by 10, still resulting in 1-second total time
through the loop. Not so! Changing the value, marked "Change this" to
a smaller value doesn't affect the time very much. It is as though
the sleep time is always at least 1000 microseconds. If this is
correct, then there should be some kind of warning that the time
can't be less than the HZ value, or whatever is limiting it.


#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/time.h>
#include <sys/select.h>

#define USEC 1e6

int main()
{
     struct timeval tv,tod;
     size_t i;
     double start_time, end_time, total_time;
     for(;;) {
         gettimeofday(&tod, NULL);		// Start time in useconds
         start_time = ((double)tod.tv_sec * USEC) + (double)tod.tv_usec;
         for(i=0; i< 1000; i++) {
             tv.tv_sec = 0;
             tv.tv_usec = 1000;		// <--- change this
             select(0, NULL, NULL, NULL, &tv);
         }
         gettimeofday(&tod, NULL);		// End time in useconds
         end_time = ((double)tod.tv_sec * USEC) + (double)tod.tv_usec;
         total_time = (end_time - start_time) / USEC;
         printf("Total time = %f seconds\n", total_time);
     }
     return 0;
}



Cheers,
Dick Johnson
Penguin : Linux version 2.6.15.4 on an i686 machine (5589.54 BogoMips).
Warning : 98.36% of all statistics are fiction, book release in April.
_
\x1a\x04

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: select takes too much time

[Nish Aravamudan]

On 4/13/06, linux-os (Dick Johnson) <linux-os@analogic.com> wrote:
>
> On Thu, 13 Apr 2006, Ram Gupta wrote:
>
> > On 4/13/06, Michal Schmidt <xschmi00@stud.feec.vutbr.cz> wrote:
> >> Ram Gupta wrote:
> >>> I am using 2.5.45 kernel but I believe the same would  be the true
> >>> for the latest kernel too.
> >>
> >> Are you just assuming this, or did you actually try a recent kernel?
> >>
> >> Michal
> >>
> >
> > I didn't get a chance to try it on a recent kernel yet but I believe
> > it to be so though I may be  wrong
> >
> > Ram
> > -
>
> Simple program here shows that you may be right! In principle,
> I should be able to multiply the loop-count by 10 and divide
> the sleep time by 10, still resulting in 1-second total time
> through the loop. Not so! Changing the value, marked "Change this" to
> a smaller value doesn't affect the time very much. It is as though
> the sleep time is always at least 1000 microseconds. If this is
> correct, then there should be some kind of warning that the time
> can't be less than the HZ value, or whatever is limiting it.

Doesn't sys_select() just use schedule_timeout() eventually? <checks>
yes, sys_select() -> core_sys_select() -> do_select() ->
schedule_timeout(). Presuming there is any value stored in the timeout
parameter, you're going to sleep at least a jiffy which is 1/HZ. If
HZ=1000 (or 1024), I'd guess that 1000 us as a minimum would be
expected.

Thanks,
Nish

Re: select takes too much time

[Michal Schmidt]

linux-os (Dick Johnson) wrote:
> It is as though the sleep time is always at least 1000
> microseconds. If this is correct, then there should be some kind of
> warning that the time can't be less than the HZ value, or whatever is
> limiting it.

Of course you can't get lower resolution than 1/HZ, unless you're using 
a kernel with high-res timers. It's always been like that.
But it's not Ram's problem, because he's requesting a timeout of 90ms, 
which is much longer than one tick even with HZ=100.

Michal

Re: select takes too much time

[Ram Gupta]

> Of course you can't get lower resolution than 1/HZ, unless you're using
> a kernel with high-res timers. It's always been like that.
> But it's not Ram's problem, because he's requesting a timeout of 90ms,
> which is much longer than one tick even with HZ=100.
>
> Michal
>

So it seems that the only solution to return back right away after
timeout is to play around with the scheduler or put the process doing
select at the front of the queue so it get a chance to run first.
Is there any other better way to do it?

Re: select takes too much time

[linux-os (Dick Johnson)]

On Fri, 14 Apr 2006, Ram Gupta wrote:

>> Of course you can't get lower resolution than 1/HZ, unless you're using
>> a kernel with high-res timers. It's always been like that.
>> But it's not Ram's problem, because he's requesting a timeout of 90ms,
>> which is much longer than one tick even with HZ=100.
>>
>> Michal
>>
>
> So it seems that the only solution to return back right away after
> timeout is to play around with the scheduler or put the process doing
> select at the front of the queue so it get a chance to run first.
> Is there any other better way to do it?
>
 	nice(-19);


Cheers,
Dick Johnson
Penguin : Linux version 2.6.15.4 on an i686 machine (5589.54 BogoMips).
Warning : 98.36% of all statistics are fiction, book release in April.
_
\x1a\x04

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: select takes too much time

[Jan Engelhardt]

>> So it seems that the only solution to return back right away after
>> timeout is to play around with the scheduler or put the process doing
>> select at the front of the queue so it get a chance to run first.
>> Is there any other better way to do it?
>>
> 	nice(-19);

	sched_setscheduler(0, SCHED_FIFO,
		(struct sched_param){.sched_priority = 99});

That should probably beat anything, with the exception of IRQs.

Jan Engelhardt
-- 

Re: select takes too much time

[Ram Gupta]

On 4/14/06, Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
> >> So it seems that the only solution to return back right away after
> >> timeout is to play around with the scheduler or put the process doing
> >> select at the front of the queue so it get a chance to run first.
> >> Is there any other better way to do it?
> >>
> >       nice(-19);
>
>         sched_setscheduler(0, SCHED_FIFO,
>                 (struct sched_param){.sched_priority = 99});
>
> That should probably beat anything, with the exception of IRQs.

Thanks a lot. I will give it a try.

regards
Ram Gupta

Re: select takes too much time

[Denis Vlasenko]

On Thursday 13 April 2006 19:11, Ram Gupta wrote:
> On 4/13/06, Andreas Mohr <andi@rhlx01.fht-esslingen.de> wrote:
> > Hi,
> >
> > Now if you have issues with select() taking too long, then I'd say tough
> > luck, that's life, other processes seem more important than y
> >
> > Or, to put it differently, select() doesn't have realtime guarantees, i.e.
> > there's no way for you to boldly assume that once select() times out
> > your process will continue to run instantly within microseconds.
> 
> I was not expecting it to run instantly within microseconds but 1
> second seemed to me too much

Which processes are running on your system?

Try to stop almost all processes and retest on almost idle machine.
It is works (wakes up in 90ms) then all is working as designed.

If you want select() to wake up earlier than competing
processes, you have to inform scheduler that your task
is "more important". Use "nice" for that.
--
vda

Re: select takes too much time

[Ram Gupta]

On 4/20/06, Denis Vlasenko <vda@ilport.com.ua> wrote:
> On Thursday 13 April 2006 19:11, Ram Gupta wrote:
> > On 4/13/06, Andreas Mohr <andi@rhlx01.fht-esslingen.de> wrote:
> > > Hi,
> > >
> > > Now if you have issues with select() taking too long, then I'd say tough
> > > luck, that's life, other processes seem more important than y


Select takes too much time only when I am having a lot of disk i/o. It
also adversely affect scheduling . It is taking too much for the
process to wake up after the timer expires. I dont see the reason why
that should happen. May be one of you may explain that.

Thanks
Ram Gupta