lkml.org 
[lkml]   [2008]   [Dec]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [4/7] dst: thread pool.
    Date
    On Wednesday 17 December 2008, Evgeniy Polyakov wrote:
    >
    > Thread pool abstraction allows to schedule a work to be performed
    > on behalf of kernel thread. One does not operate with threads itself,
    > instead user provides setup and cleanup callbacks for thread pool itself,
    > and action and cleanup callbacks for each submitted work.
    >
    > Each worker has private data initialized at creation time and data,
    > provided by user at scheduling time.
    >
    > When action is being performed, thread can not be used by other users,
    > instead they will sleep until there is free thread to pick their work.
    >
    > Thread pool is used for crypto processing of incoming and outgoing IO
    > requests to reduce the overall overhead.
    >
    > Signed-off-by: Evgeniy Polyakov <zbr@ioremap.net>

    Have you looked at the last discussion involving thread pools in Linux?
    BenH brought up the topic earlier this year, it is archived on
    https://lists.linux-foundation.org/pipermail/ksummit-2008-discuss/2008-July/000213.html

    So while it seems that there is clearly a use for such infrastructure,
    my feeling is that it should not be part of dst, but rather live
    in a location where it can be used by every subsystem.

    Of course getting it there means another flame war^W^W discussion about what
    the right interface should look like.

    My personal feeling is that the interface should look a lot like
    the existing work queues, to the point where you can easily convert
    drivers between them, or even move all work queues over to thread pools.

    Arnd <><


    \
     
     \ /
      Last update: 2008-12-17 16:57    [W:0.046 / U:0.020 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site