linux-kernel - Re: [take25 1/6] kevent: Description.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	24 Nov 2006 13:07:26 GMT
From:	"Miquel van Smoorenburg" <miquels@...tron.nl>
To:	linux-kernel@...r.kernel.org
Subject: Re: [take25 1/6] kevent: Description.

In article <45663298.7000108@...hat.com>,
Ulrich Drepper  <drepper@...hat.com> wrote:
>Jeff Garzik wrote:
>> Considering current designs, it seems more likely that a single thread 
>> polls for socket activity, then dispatches work.  How often do you 
>> really see in userland multiple threads polling the same set of fds, 
>> then fighting to decide who will handle raised events?
>> 
>> More likely, you will see "prefork" (start N threads, each with its own 
>> ring) or a worker pool (single thread receives events, then dispatches 
>> to multiple threads for execution) or even one-thread-per-fd (single 
>> thread receives events, then starts new thread for handling).
>
>No, absolutely not.  This is exactly not what should/is/will happen.
>
>You create worker threads to handle to work for the entire program. 
>Look at something like a web server.  When creating several queues, how 
>do you distribute all the connections to the different queues?  To 
>ensure every connection is handled as quickly as possible you stuff them 
>all in the same queue and then have all threads use this one queue. 
>Whenever an event is posted a thread is woken.  _One_ thread.  If two 
>events are posted, two threads are woken.  In this situation we have a 
>few atomic ops at userlevel to make sure that the two threads don't pick 
>the same event but that's all there is wrt "fighting".

What you really want is if one thread is able to do all the work,
only keep that one thread busy. Only wake up other threads when
the currently running threads cannot handle the load.

Say you have 8 threads blocked in kevent_wait(). One or more events
become available. You wake one thread, and let it run.

If the one thread has done its work and returns to kevent_wait()
before its timeslice has run out, deliver the next event(s) (which
may already be outstanding) to the same thread, don't wake another one.

If the running thread blocks on say disk i/o, or its timeslice
runs out, the scheduler runs and wakes another thread that is
waiting in kevent_wait().

Mike.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/