Re: [RFC PATCH 5/5] epoll: introduce epoll connected components (remove the epmutex)

[Eric Wong]

Jason Baron <jbaron@xxxxxxxxxx> wrote:
> I've done a bit of performance evaluation on a dual socket, 10 core, hyper
> threading enabled box: Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz. For the
> simple epfdN->epfdN->pipefdN topology case where each thread has its
> own unique files and is doing EPOLL_CTL_ADD and EPOLL_CTL_DEL on the pipefd,
> I see an almost 300% improvement. This is obviously a very contrived case,
> but shows the motivation for this patch.

Any improvements for non-contrived cases? :)

> +++ b/include/linux/fs.h
> @@ -835,6 +835,9 @@ struct file {
>  	/* Used by fs/eventpoll.c to link all the hooks to this file */
>  	struct list_head	f_ep_links;
>  	struct list_head	f_tfile_llink;
> +	/* connected component */
> +	struct list_head	f_ep_cc_link;
> +	struct ep_cc __rcu	*f_ep_cc;
>  #endif /* #ifdef CONFIG_EPOLL */

This size increase worries me.  Perhaps this can be a separately
allocated struct to avoid penalizing non-epoll users?

	struct file_eventpoll {
		struct list_head	f_ep_links;
		struct list_head	f_tfile_llink;
		/* connected component */
		struct list_head	f_ep_cc_link;
		struct ep_cc __rcu	*f_ep_cc;
	};

But I wish Linux never allowed nesting epoll in the first place :/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/