[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150115231051.GA24252@dcvr.yhbt.net>
Date: Thu, 15 Jan 2015 23:10:51 +0000
From: Eric Wong <normalperson@...t.net>
To: Jason Baron <jbaron@...mai.com>
Cc: akpm@...ux-foundation.org, famz@...hat.com, nzimmer@....com,
viro@...iv.linux.org.uk, davidel@...ilserver.org,
rostedt@...dmis.org, linux-kernel@...r.kernel.org,
linux-fsdevel@...r.kernel.org
Subject: Re: [RFC PATCH 5/5] epoll: introduce epoll connected components
(remove the epmutex)
Jason Baron <jbaron@...mai.com> 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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists