lkml.org 
[lkml]   [2006]   [Jul]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC 1/4] kevent: core files.
    On Mon, Jul 24, 2006 at 11:17:08PM -0700, David Miller (davem@davemloft.net) wrote:
    > From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
    > Date: Sun, 9 Jul 2006 17:24:46 +0400
    >
    > > This patch includes core kevent files:
    > > - userspace controlling
    > > - kernelspace interfaces
    > > - initialisation
    > > - notification state machines
    > >
    > > It might also inlclude parts from other subsystem (like network related
    > > syscalls so it is possible that it will not compile without other
    > > patches applied).
    > >
    > > Signed-off-by: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
    >
    > I like this work a lot, as I've stated before. The data structures
    > look like they will scale well and it takes care of all the limitations
    > that networking in particular seems to have in this area.
    >
    > I have to say that the user API is not the nicest in the world. Yet,
    > at the same time, I cannot think of a better one :)

    Hi David. I see you have a day of backlog mails processing :)

    > Please, remove some grot such as this:
    >
    > > + if (kevent_cache)
    > > + k = kmem_cache_alloc(kevent_cache, mask);
    > > + else
    > > + k = kzalloc(sizeof(struct kevent), mask);
    > ...
    > > + if (kevent_cache)
    > > + kmem_cache_free(kevent_cache, k);
    > > + else
    > > + kfree(k);
    >
    > Instead, make this:
    >
    > > + kevent_cache = kmem_cache_create("kevent_cache",
    > > + sizeof(struct kevent), 0, 0, NULL, NULL);
    > > + if (!kevent_cache)
    > > + err = -ENOMEM;
    >
    > panic(). This is consistent with how other core subsystems handle
    > SLAB cache creation failures.

    Ok.

    > I also think that if we accept this work, it should be first class
    > citizen with no config options and no ifdefs scattered all over.
    > Either this is how we do network AIO or it is not.
    >
    > I've looked only briefly at Ulrich Drepper's AIO proposal in his OLS
    > slides, although the DMA bits do not initially strike me as such a hot
    > idea. I haven't wrapped my brain much around this new stuff, so I'm
    > not going to touch on it much more just yet.

    Yes, his idea of dma alloc is extremely good.
    I manage it with quite big overhead in kevent unfortunately.
    All other topics are fully covered with kevent (except nice userspace
    API of course :) )

    > The practical advantage kevent has over any new proposal is that 1)
    > implementation exists :) and 2) several types of test applications and
    > performance measurements have been made against it which usually
    > flushes out the worst design issues.

    I will clean code up and resubmit today.
    Thank you.

    --
    Evgeniy Polyakov
    -
    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: 2006-07-25 08:29    [W:3.034 / U:0.200 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site