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

* Ingo Molnar <> wrote:

> * Zach Brown <> 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:

let me clarify this: i very much like your AIO patchset in general, in
the sense that it 'completes' the AIO implementation: finally everything
can be done via it, greatly increasing its utility and hopefully its
penetration. This is the most important step, by far.

what i dont really like /the particular/ concept above - the
introduction of 'fibrils' as a hard distinction of kernel threads. They
are /almost/ kernel threads, but still by being different they create
alot of duplication and miss out on a good deal of features that kernel
threads have naturally.

It kind of hurts to say this because i'm usually quite concept-happy -
one can easily get addicted to the introduction of new core kernel
concepts :-) But i really, really think we dont want to do fibrils but
we want to do kernel threads, and i havent really seen a discussion
about why they shouldnt be done via kernel threads.

Nor have i seen a discussion that whatever threading concept we use for
AIO within the kernel, it is really a fallback thing, not the primary
goal of "native" KAIO design. The primary goal of KAIO design is to
arrive at a state machine - and for one of the most important IO
disciplines, networking, that is reality already. (For filesystem events
i doubt we will ever be able to build an IO state machine - but there
are lots of crazy folks out there so it's not fundamentally impossible,
just very, very hard.)

so my suggestions center around the notion of extending kernel threads
to support the features you find important in fibrils:

> 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.)

but i'm willing to be convinced of the opposite as well, as always. (I'm
real good at quickly changing my mind, especially when i'm embarrasingly
wrong about something. So please fire away and dont hold back.)

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-01 14:07    [W:0.260 / U:2.884 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site