chicken-hackers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-hackers] PATCH: more efficient scheduler


From: Jörg F . Wittenberger
Subject: Re: [Chicken-hackers] PATCH: more efficient scheduler
Date: Wed, 17 Feb 2016 16:41:52 +0100
User-agent: Mozilla/5.0 (X11; Linux armv7l; rv:38.0) Gecko/20100101 Icedove/38.4.0

Am 17.02.2016 um 15:37 schrieb Andy Bennett:
> Hi Jörg,
> 
> Do you think this patch would affect the issue I was seeing in my 2015
> mail to chicken-users "http-client gets stuck in scheduler when reusing
> connect"?
> (https://lists.gnu.org/archive/html/chicken-users/2015-06/msg00056.html )

Hard to guess.

It may affect it just because it avoids to poll so often.  But this
depends on what else is going on in your program.  If there are other
threads to run it may be worth a try.

At the other hand I don't think so, because you indicate that you're
basically seeing no load in "user" and "sys" but "real" time elapses.  A
quick search on "__poll_nocancel" returns quite a lot.  So this seems to
be something else.

> 
> 
> 
> 
>> the attached patch does not fix any bugs.  It brings some performance
>> improvements under certain load conditions.  The cost: It adds the
>> overhead of another counter and a dispatch on a a fixnum modulo
>> operation - IMHO negotiable.
>>
>> The change is helpful when sits watching on several file descriptors for
>> requests _and_ uses several threads, message passing etc. to produce
>> responses.
>>
>> Under these circumstances I found a common call pattern to be few file
>> descriptors to become available resulting in many internal threads
>> forked.  Those threads have often very little actual work to do until
>> the block again.  At this point each ##sys#schedule will check those
>> file descriptors again and again - typically not returning any fd until
>> after all those threads completed eventually.  This results in a pretty
>> huge delay of the response.
>>
>> With the change there is now a "pending-queue".  This holds all the
>> threads to be run once before we even check for new work from timeouts
>> or i/o.  Furthermore we only check for i/o at an adjustable rate or if
>> we would wait otherwise.
>>
>> I have a test case where there are about 50 threads waiting on input and
>> observed up to 200 in state "ready" to pass messages among each other at
>> a time.  Those saved i/o times add up to a difference of about 30%
>> faster responses.
>>
>> Best
>>
>> /Jörg
>>
>>
>>
>> _______________________________________________
>> Chicken-hackers mailing list
>> address@hidden
>> https://lists.nongnu.org/mailman/listinfo/chicken-hackers
>>
> 
> 
> 
> 
> 
> Regards,
> @ndy
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]