[lkml]   [2007]   [Feb]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch 00/11] ANNOUNCE: "Syslets", generic asynchronous system call support
    On Tue, 13 Feb 2007, Ingo Molnar wrote:

    > I'm pleased to announce the first release of the "Syslet" kernel feature
    > and kernel subsystem, which provides generic asynchrous system call
    > support:
    > [...]

    Ok, I had little to time review the code, but it has been a long
    working day, so bear with me if I missed something.
    I don't see how sys_async_exec would not block, based on your patches.
    Let's try to follow:

    - We enter sys_async_exec

    - We may fill the pool, but that's nothing interesting ATM. A bunch of
    threads will be created, and they'll end up sleeping inside the

    - We set the async_ready pointer and we fall inside exec_atom

    - There we copy the atom (nothing interesting from a scheduling POV) and
    we fall inside __exec_atom

    - In __exec_atom we do the actual syscall call. Note that we're still the
    task/thread that called sys_async_exec

    - So we enter the syscall, and now we end up in schedule because we're
    just unlucky

    - We notice that the async_ready pointer is not NULL, and we call

    - Finally we're in pick_new_async_thread and we pick one of the ready
    threads sleeping in cachemiss_loop

    - We copy the pt_regs to the newly picked-up thread, we set its async head
    pointer, we set the current task async_ready pointer to NULL, we
    re-initialize the async_thread structure (the old async_ready), and we
    put ourselves in the busy_list

    - Then we roll back to the schedule that started everything, and being
    still "prev" for the scheduler, we go to sleep

    So the sys_async_exec task is going to block. Now, am I being really
    tired, or the cachemiss fast return is simply not there?
    There's another problem AFAICS:

    - We woke up one of the cachemiss_loop threads in pick_new_async_thread

    - The threads wakes up, mark itself as busy, and look at the ->work
    pointer hoping to find something to work on

    But we never set that pointer to a userspace atom AFAICS. Me blind? :)

    - Davide

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-02-14 04:33    [W:0.042 / U:8.804 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site