From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752904AbbAUKiY (ORCPT ); Wed, 21 Jan 2015 05:38:24 -0500 Received: from mx1.redhat.com ([209.132.183.28]:46207 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750812AbbAUKiM (ORCPT ); Wed, 21 Jan 2015 05:38:12 -0500 Message-ID: <54BF814F.7090703@redhat.com> Date: Wed, 21 Jan 2015 11:37:03 +0100 From: Paolo Bonzini User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Fam Zheng , "Michael Kerrisk (man-pages)" , Andy Lutomirski CC: linux-kernel@vger.kernel.org, Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, Alexander Viro , Andrew Morton , Kees Cook , David Herrmann , Alexei Starovoitov , Miklos Szeredi , David Drysdale , Oleg Nesterov , "David S. Miller" , Vivek Goyal , Mike Frysinger , "Theodore Ts'o" , Heiko Carstens , Rasmus Villemoes , Rashika Kheria , Hugh Dickins , Mathieu Desnoyers , Peter Zijlstra , linux-fsdevel@vger.kernel.org, linux-api@vger.kernel.org, Josh Triplett Subject: Re: [PATCH RFC 5/6] epoll: Add implementation for epoll_mod_wait References: <1421747878-30744-1-git-send-email-famz@redhat.com> <1421747878-30744-6-git-send-email-famz@redhat.com> <54BE4F1D.7090807@gmail.com> <20150121045903.GA2858@fam-t430.nay.redhat.com> <54BF5ACE.6030206@gmail.com> <20150121085827.GB23024@ad.nay.redhat.com> In-Reply-To: <20150121085827.GB23024@ad.nay.redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 21/01/2015 09:58, Fam Zheng wrote: >> > See my comment in the earlier mail. If you split this into two >> > APIs, and epoll_ctl_batch() is guaranteed to execute 'cmds' in order, >> > then the return value of epoll_ctl_batch() could be used to tell >> > user space how many commands succeeded. Much simpler! > Yes it is much simpler. However the reason to add batching in the first place is > to make epoll faster, by reducing syscalls. Splitting makes the result > sub-optimal: we still need at least 2 calls instead of 1. Each one of the three > proposed new call *is* a step forward, but I don't think we will have everything > solved even by implementing them all. Compromise needed between performance or > complexity. > > My take for simplicity will be leaving epoll_ctl as-is, and my take for > performance will be epoll_pwait1. And I don't really like putting my time on > epoll_ctl_batch, thinking it as a ambivalent compromise in between. I agree with Michael actually. The big change is going from O(n) epoll_ctl calls to O(1), and epoll_ctl_batch achieves that just fine. Changing 2 syscalls to 1 is the icing on the cake, but we're talking of a fraction of a microsecond. Paolo