Re: [RFC 1/4] kevent: core files.

[David Miller <davem@davemloft.net>]

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

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.

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.

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