Received: by 10.223.164.221 with SMTP id h29csp3988246wrb; Tue, 31 Oct 2017 08:00:09 -0700 (PDT) X-Google-Smtp-Source: ABhQp+RKoabIf5SsF32uy9wKCFXzbR0BEKPjFdsF3Zxbm46qv7FO2zPDE3eQegb1PsF5OgbCbhj7 X-Received: by 10.98.73.67 with SMTP id w64mr2350831pfa.338.1509462009523; Tue, 31 Oct 2017 08:00:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1509462009; cv=none; d=google.com; s=arc-20160816; b=A227si6zY+x0J16EyPKMPhIA15DvJFgw28vMpMs4lw9QEdTGB3dT+w0TyWLj2fas5z GQz/1OJg6662vDL2LLlnGWTFePoGhD77RcqsRJ4xi6tUFf7D5H2Ow/70Ct35Zas4gYa4 otoSG1GmdRCCGk1a8+HRTciD6RnxH7dipL4Og8SGQtd49jxMwESIz1z/P3uwQQGdqVBm 5ZgpSS5wTcHRXrMtUzerKdhRSI5ezXBrB+5OOPmzigsPfBxiLbvssuYTA064Vpv25Hpz ls1EhkNRmpSZlbE/tdBUW6/2AwPW9GsdxRTq4hmE5VOeQKWTeFdjnHsE+BKMD4CkTBsn PAdQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=vzJcG4J3QyV1dVELM+8ng9gYaVulx4rN+Ro65HY8tsg=; b=YCunDbKuKDij183z7FWNaRAfxX0W3pp+6O7Jf+XEsr6WgiRjdExY+GcRM+WsHlxFb5 4p5RxdxmZYM2WsWaAGmvq/rFpPHRsGEGtk4xhYHDlqH61gLEZyuqQALfgtMKJ8NSi1bd VCAoaoRiPhmrI/2hzQH2eyvsYy7kTfeCUQ/FJqGfHB5cAxBqv+jXtuzrzWW/kBP6RB1O K4mgLx2VX6IgeKbtZ84LsL91WaBSIIAfy/UfUYu+Yld6S9Gz+9VKFIn/DoanO6/05Rvt 54QvmFVydvdeW9NZl4zjimR7yYY3rENtnNLTpYr1MHHPT2AgQxYIYv2wnE/o87/DlOnk LmFg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w20si1748197plp.471.2017.10.31.07.59.55; Tue, 31 Oct 2017 08:00:09 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753342AbdJaO7X (ORCPT + 99 others); Tue, 31 Oct 2017 10:59:23 -0400 Received: from mx2.suse.de ([195.135.220.15]:56334 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751366AbdJaO7V (ORCPT ); Tue, 31 Oct 2017 10:59:21 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 5989EADEA; Tue, 31 Oct 2017 14:59:20 +0000 (UTC) Date: Tue, 31 Oct 2017 07:58:21 -0700 From: Davidlohr Bueso To: Jason Baron Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org, Alexander Viro , Salman Qazi , Hou Tao Subject: Re: [PATCH] epoll: remove ep_call_nested() from ep_eventpoll_poll() Message-ID: <20171031145821.ieflhlvs3la25vdw@linux-n805> References: <1509430214-5599-1-git-send-email-jbaron@akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <1509430214-5599-1-git-send-email-jbaron@akamai.com> User-Agent: NeoMutt/20170421 (1.8.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 31 Oct 2017, Jason Baron wrote: >The use of ep_call_nested() in ep_eventpoll_poll(), which is the .poll >routine for an epoll fd, is used to prevent excessively deep epoll >nesting, and to prevent circular paths. However, we are already preventing >these conditions during EPOLL_CTL_ADD. In terms of too deep epoll chains, >we do in fact allow deep nesting of the epoll fds themselves (deeper >than EP_MAX_NESTS), however we don't allow more than EP_MAX_NESTS when >an epoll file descriptor is actually connected to a wakeup source. Thus, >we do not require the use of ep_call_nested(), since ep_eventpoll_poll(), >which is called via ep_scan_ready_list() only continues nesting if there >are events available. Since ep_call_nested() is implemented using a global >lock, applications that make use of nested epoll can see large performance >improvements with this change. Improvements are quite obscene actually, such as for the following epoll_wait() benchmark with 2 level nesting on a 80 core IvyBridge: ncpus vanilla dirty delta 1 2447092 3028315 +23.75% 4 231265 2986954 +1191.57% 8 121631 2898796 +2283.27% 16 59749 2902056 +4757.07% 32 26837 2326314 +8568.30% 64 12926 1341281 +10276.61% (http://linux-scalability.org/epoll/epoll-test.c) Thanks, Davidlohr From 1582752471322086730@xxx Tue Oct 31 06:13:01 +0000 2017 X-GM-THRID: 1582752471322086730 X-Gmail-Labels: Inbox,Category Forums