[Click] click 1.8.0 Unqueue2 -> 100% CPU usage

Eddie Kohler kohler at cs.ucla.edu
Thu Jun 23 22:15:25 EDT 2011


BTW, I checked in a change that should make Unqueue2 listen to notifiers -- 
but I still think it might be better to just remove Unqueue2 altogether.

Eddie


On 06/23/2011 07:11 PM, R H wrote:
> Hi Lars,
>
> The same script works fine when replacing Unqueue2 with Unqueue without changing the InfiniteSource configurations.  So I don't think it is a timer issue.  As Beyers pointed out and looking at the source code, Unqueue2 does not listen to queue empty signals sent from the NotifierQueue and keeps checking for packets.
>
> Regards,
> Raja
>
>
> ________________________________
> From: Lars Bro<larsbro at gmail.com>
> To: R H<rajamhayek at yahoo.com>
> Cc: click at pdos.csail.mit.edu
> Sent: Thursday, June 23, 2011 1:51 AM
> Subject: Re: [Click] click 1.8.0 Unqueue2 ->  100% CPU usage
>
> Hello, Raja
>
> I think, this is because of the way Click timers work. A Click timer
> is *very* precise, and this is achieved by so to say "spinning on
> gettimeofday()" For example, if You want to sleep 753.332 milisecond,
> it wil sleep normally for the first 750 miliseconds, and then
> busy-wait on the timer for the last three miliseconds. I dont know the
> threshold, but you are requesting something to take place every
> 1000/75 = 13 miliseconds, which may mean that the process is
> busy-waiting all the time, using all of the CPU. You can try changing
> the 75 to below 50, I guess the limit is 20 msec.
>
> You must remember that all other timers in Click are still just as
> precise, so the only effect is that the Click process uses CPU. Click
> itself does fine. You must also remember that the time-sharing
> scheduler on your system will soon find out that the Click process can
> easily be scheduled out in favor of other user processes.
>
> You can try to do the same when a heavy compilation is also running on
> that processor, and then watch the accuracy of the Click process. You
> should come to the result that even when compiling, the Click process
> is very accurate.
>
> yours,
> Lars Bro
>
>
> On Thu, Jun 23, 2011 at 2:41 AM, R H<rajamhayek at yahoo.com>  wrote:
>> Hi,
>>
>> Using the following sample configuration, I get 100% CPU usage even after the InfiniteSource finishes sending the 100 packets; but if I replace Unqueue2 with Unqueue everything works well.  Looked at the documentation and they both default to pulling 1 packet when scheduled until there is nothing to pull.  What am I missing?
>>
>> s :: InfiniteSource(\<0800>, RATE 75, LIMIT 100, STOP false); //random numbers as long as it does not stop!
>>
>> q :: NotifierQueue(200);
>> uq :: Unqueue2();
>> p :: Print();
>>
>> d :: Discard;
>>
>> s->q->uq->p->d;
>>
>> Thanks,
>> Raja
>> _______________________________________________
>> click mailing list
>> click at amsterdam.lcs.mit.edu
>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>>
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click


More information about the click mailing list