lkml.org 
[lkml]   [2007]   [Feb]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 2 of 4] Introduce i386 fibril scheduling

    * Zach Brown <zach.brown@oracle.com> wrote:

    > This patch introduces the notion of a 'fibril'. It's meant to be a
    > lighter kernel thread. [...]

    as per my other email, i dont really like this concept. This is the
    killer:

    > [...] There can be multiple of them in the process of executing for a
    > given task_struct, but only one can every be actively running at a
    > time. [...]

    there's almost no scheduling cost from being able to arbitrarily
    schedule a kernel thread - but there are /huge/ benefits in it.

    would it be hard to redo your AIO patches based on a pool of plain
    simple kernel threads?

    We could even extend the scheduling properties of kernel threads so that
    they could also be 'companion threads' of any given user-space task.
    (i.e. they'd always schedule on the same CPu as that user-space task)

    I bet most of the real benefit would come from co-scheduling them on the
    same CPU. But this should be a performance property, not a basic design
    property. (And i also think that having a limited per-CPU pool of AIO
    threads works better than having a per-user-thread pool - but again this
    is a detail that can be easily changed, not a fundamental design
    property.)

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

    \
     
     \ /
      Last update: 2007-02-01 09:41    [W:4.117 / U:1.208 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site