From patchwork Fri Oct 28 21:43:20 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jens Axboe X-Patchwork-Id: 852 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp1058338wru; Fri, 28 Oct 2022 14:46:26 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6X3Y7UDyNq3O2uyaIi/1T6/Tb8AFUZdCaRYGIP8/otiQPVCtCYFpmoqi8YIhexeZkFgFhq X-Received: by 2002:a17:907:9707:b0:78d:45d1:487e with SMTP id jg7-20020a170907970700b0078d45d1487emr1264240ejc.566.1666993586102; Fri, 28 Oct 2022 14:46:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666993586; cv=none; d=google.com; s=arc-20160816; b=I6vIKmWxb+lmiJ+wXqRFdcocSsJpGycEqnTxJTonxRB4/uUwid3qsAssZkVFxZffEF Lr0G9tJ8tpvrqpUQVL+jl4KSbjUSSxtowubjgOVi/EQDGkHz8c7g4hCpbfFtpXmhD3sN eUuJWyMpMnHTxhC7jSFSJVcFYEx/A4cXrirZyHM6TXxPtxqnLhg53XTVylLvLZ2FdRg+ PwF459XR09ld56AS1WdQi4qBt8yn+0nMFNEHPK0b7MhapoozZsu7XM40uT06XfL7QMCP 0PtbLahRuYs8LM+SWJhbHLBTzUAyTTsFYhm+lsmB/PmzV6lsN8kPzs8DBNrSMhhAGmXa JlJQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:to:from:dkim-signature; bh=Sx0EMO7RuJTo/3Ojp2nIxuOlr6+N1nhbsLyvkyaiQXQ=; b=fmGnyyFQAhTOp2hf2uDV3HmlpKTvJhiMECLNdahtwPlepB7Fk6cM84vDqxQK5ExprH PG4Zo2aW8Xs5/jy6/WEQQLxL92xhCMtcHtUaj/P3WBosXXAm8kHQax1f5klwV0YYXC/z aPbCTeCddztA0NlPFQEbml2IXAawM8yRC8F9vyO8DiB5B+sBbaEtak6IBfDNKaNva0C5 WcCm89+Sq1HCQHa0fAodtTMMYo9ObAXtAzTHKgN+2xs4RDtXpdygTsDs5+lIxO7z6UK7 0o+aQjHkHbHRiOcDPhQ0hJ+E9kWCDVJ820xp9t7zuoUvSEPGWMbef647tzg01REWQN1r 5h7g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel-dk.20210112.gappssmtp.com header.s=20210112 header.b=tThyWqEH; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id hz2-20020a1709072ce200b0077cdcd4ed23si1325155ejc.498.2022.10.28.14.46.02; Fri, 28 Oct 2022 14:46:26 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel-dk.20210112.gappssmtp.com header.s=20210112 header.b=tThyWqEH; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230010AbiJ1Vnf (ORCPT + 99 others); Fri, 28 Oct 2022 17:43:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39860 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230013AbiJ1Vnc (ORCPT ); Fri, 28 Oct 2022 17:43:32 -0400 Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5B7D524B33C for ; Fri, 28 Oct 2022 14:43:30 -0700 (PDT) Received: by mail-pg1-x535.google.com with SMTP id f9so5931695pgj.2 for ; Fri, 28 Oct 2022 14:43:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:to :from:from:to:cc:subject:date:message-id:reply-to; bh=Sx0EMO7RuJTo/3Ojp2nIxuOlr6+N1nhbsLyvkyaiQXQ=; b=tThyWqEH+OHSWnyvXVnGVb/RhwKNJAox7Ss2mhO1vSdRKT3Ewr1p0KrR11/iwka97g AiLMqsg0mEuabgBywD/d2wh1f9R0qRd3mQs0FqYWbOQY9HxaCHHZtrsbrUWRFZWsW64h iGs3V597/zcdRu068jxDXK40pzFV1K9lKSx2z6lPRCwVULPx0fPWJigIk5pAIeepHkmL OPAPPRTj2XsThLV1wZLIS9zkYy+/viHeG6K9gNO9wA1MlRI+cAicnc78S7aas1IF0Y1m K8suSyr7Ii3VHFQQm7xB0SdEO4hZWjpWXepl6iImu7sInL19Qus+calIQVHZ6MQHObJw lfbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Sx0EMO7RuJTo/3Ojp2nIxuOlr6+N1nhbsLyvkyaiQXQ=; b=N7mk7wfdP0K1WTmDF2RNGGBC1i5vzrIKTLYYuv3c50wMawWhdUSmbT5fZGTqyZYwQC DoQoFiMPsTy7M/gJsoG/nDYcbvewvz/+kpk0tyem/jRBMQDfK6c/HebXOT5MCaHeURWO r01O8dA/vNmSVmk4OMGxk6Kel6eGKG6xDQ0jW+lF5wseSiae8dB+jJEVtTeevAmwYW8n LAqK5HorGbgQyTbSEh1h7T7PNraP0j/aTczwyv1Ws07prEndcxyQJfixO2Rvv2Dw+bkb jXA8R62WgfucI9Zw1S9X10fW+1HvuhGLE91Dzgaw7NZOFAZy8mOV56NS5nGPaiB5EIsV MHaA== X-Gm-Message-State: ACrzQf2se9QlBui6PJemBJOQkqeAeGAHMZecUEDty9jM66WvMlniDVv+ n0vDwFphSstdd0KlXKwj8kJJRBHapz0iC8S8 X-Received: by 2002:a65:49c9:0:b0:462:9ce1:3f58 with SMTP id t9-20020a6549c9000000b004629ce13f58mr1389282pgs.200.1666993409506; Fri, 28 Oct 2022 14:43:29 -0700 (PDT) Received: from localhost.localdomain ([198.8.77.157]) by smtp.gmail.com with ESMTPSA id u6-20020a17090a1d4600b002130c269b6fsm2993855pju.1.2022.10.28.14.43.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 28 Oct 2022 14:43:29 -0700 (PDT) From: Jens Axboe To: linux-kernel@vger.kernel.org, netdev@vger.kernel.org Subject: [PATCHSET RFC v2 0/5] Add support for epoll min_wait Date: Fri, 28 Oct 2022 15:43:20 -0600 Message-Id: <20221028214325.13496-1-axboe@kernel.dk> X-Mailer: git-send-email 2.35.1 MIME-Version: 1.0 X-Spam-Status: No, score=1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,RCVD_IN_SBL_CSS,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.6 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1747969466428986520?= X-GMAIL-MSGID: =?utf-8?q?1747969466428986520?= Hi, tldr - we saw a 6-7% CPU reduction with this patch. See patch 4 for full numbers. This adds support for EPOLL_CTL_MIN_WAIT, which allows setting a minimum time that epoll_wait() should wait for events on a given epoll context. Some justification and numbers are in patch 5, patches 1-4 are really just prep patches. Sending this as an RFC to hash out the API, basically. This is obviously a per-context type of operation in this patchset, which isn't necessarily ideal for any use case. Questions to be debated: 1) Would we want this to be available through epoll_wait() directly? That would allow this to be done on a per-epoll_wait() basis, rather than be tied to the specific context. 2) If the answer to #1 is yes, would we still want EPOLL_CTL_MIN_WAIT? I think there are pros and cons to both, and perhaps the answer to both is "yes". There are some benefits to doing this at epoll setup time, for example - it nicely isolates it to that part rather than needing to be done dynamically everytime epoll_wait() is called. This also helps the application code, as it can turn off any busy'ness tracking based on if the setup accepted EPOLL_CTL_MIN_WAIT or not. Anyway, tossing this out there as it yielded quite good results in some initial testing, we're running more of it. Not a lot of changes since v1, but it was posted in the middle of the merge window. Hoping to get some more discussion this time around, or at least some... Also available here: https://git.kernel.dk/cgit/linux-block/log/?h=epoll-min_ts Since v1: - Split patch 4 a bit, to make the meat of the changes smaller - Get rid of EPOLL_DEF_MIN_WAIT - Rebase on current -git master