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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <54B9445C.4070800@akamai.com>
Date:	Fri, 16 Jan 2015 12:03:24 -0500
From:	Jason Baron <jbaron@...mai.com>
To:	Eric Wong <normalperson@...t.net>, 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)

On 01/15/2015 06:10 PM, Eric Wong wrote:
> 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? :)

I plan to do some more testing and will post performance findings...

>> +++ 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?

Agreed. That was why I marked this RFC. I was planning to try and shrink
some of the lists to singly-linked lists. But I think breaking it out as 'file_eventpoll'
is a good suggestion. We could simply just always allocate it for an epfd,
and then just allocate it for a 'regular' struct file on the first EPOLL_CTL_ADD.
That would actually result in a net shrinkage of the 'struct file' by 3 pointers from
where we are today. So I think that would be nice.

Thanks,

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