On Mon, Jul 24, 2006 at 11:17:08PM -0700, David Miller ([email protected]) wrote:
> From: Evgeniy Polyakov <[email protected]>
> 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 <[email protected]>
>
> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
