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:0.151 / U:0.556 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site