Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932770Ab2JRSFS (ORCPT ); Thu, 18 Oct 2012 14:05:18 -0400 Received: from mail-pb0-f46.google.com ([209.85.160.46]:59994 "EHLO mail-pb0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932725Ab2JRSFP (ORCPT ); Thu, 18 Oct 2012 14:05:15 -0400 Message-ID: <508044D7.7070005@mit.edu> Date: Thu, 18 Oct 2012 11:05:11 -0700 From: Andy Lutomirski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1 MIME-Version: 1.0 To: Andrew Morton CC: mtk.manpages@gmail.com, "Paton J. Lewis" , Alexander Viro , Jason Baron , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Paul Holland , Davide Libenzi , libc-alpha@sourceware.org, Linux API , paulmck@linux.vnet.ibm.com Subject: Re: [PATCH v2] epoll: Support for disabling items, and a self-test app. References: <1345756535-8372-1-git-send-email-palewis@adobe.com> <20121017163004.fb9de1b3.akpm@linux-foundation.org> In-Reply-To: <20121017163004.fb9de1b3.akpm@linux-foundation.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2814 Lines: 73 [cc Paul McKenney, who is probably the leading expert on these things] On 10/17/2012 04:30 PM, Andrew Morton wrote: > On Tue, 16 Oct 2012 17:12:57 +0200 > "Michael Kerrisk (man-pages)" wrote: > >> On Thu, Aug 23, 2012 at 11:15 PM, Paton J. Lewis wrote: >>> From: "Paton J. Lewis" >>> >>> Enhanced epoll_ctl to support EPOLL_CTL_DISABLE, which disables an epoll item. >>> If epoll_ctl doesn't return -EBUSY in this case, it is then safe to delete the >>> epoll item in a multi-threaded environment. Also added a new test_epoll self- >>> test app to both demonstrate the need for this feature and test it. >> >> (There's a lot of background missing from this version of the patch >> that was included in the previous version >> [http://thread.gmane.org/gmane.linux.kernel/1311457]. It helps to >> include the full rationale with a revised patch--best not to assume >> that someone has the context of past mails when reading a revised >> patch.) >> >> I've taken a look at this patch as it currently stands in 3.7-rc1, and >> done a bit of testing. (By the way, the test program >> tools/testing/selftests/epoll/test_epoll.c does not compile...) > > Thanks for this. You raise significant issues. If we can't get these > fully resolved over the next month or so, we should revert the patch so > this new API doesn't get released in 3.7. I have queued a patch to do > this and shall maintain it while I watch developments... I can't shake the feeling that EPOLL_CTL_DISABLE is solving a non-problem, or, more precisely, that there should be a perfectly good userspace solution with no kernel changes. Unless something is rather buggy in kernel land (and I don't think it is), once EPOLL_CTL_DEL has returned, no call to epoll_wait that starts *after* EPOLL_CTL_DEL finishes will return that object. This suggests an RCU-like approach: once EPOLL_CTL_DEL has returned and every thread has returned from an epoll_wait call that started after the EPOLL_CTL_DEL returns, then the data structure can be safely freed. In pseudocode: delete(fd, pdata) { pdata->dead = true; EPOLL_CTL_DEL(fd); rcu_call(delete pdata); } wait() { epoll_wait; for each event pdata { if (pdata->gone) continue; process the event; } rcu_this_is_a_grace_period(); } Of course, these are not normal grace periods and would need to be tracked separately. (The optimal data structure to do this without killing scalability is not obvious. urcu presumably implements such a thing.) Am I right? --Andy -- 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/