From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 450ECC6FD18 for ; Wed, 19 Apr 2023 02:15:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230340AbjDSCPI (ORCPT ); Tue, 18 Apr 2023 22:15:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49204 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229633AbjDSCPH (ORCPT ); Tue, 18 Apr 2023 22:15:07 -0400 Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8E02E2681 for ; Tue, 18 Apr 2023 19:15:05 -0700 (PDT) Received: by mail-pf1-x430.google.com with SMTP id d2e1a72fcca58-63d32d21f95so400527b3a.1 for ; Tue, 18 Apr 2023 19:15:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20221208.gappssmtp.com; s=20221208; t=1681870505; x=1684462505; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=omaGeiilnWY8neqCu1aYblokWGcDA5y3QiHgOwpl4SY=; b=jDO842tOQzUGfFMlpnl+0xVX3t6R3u7QMAu+s1WrMuaCVxUVgycP/Phvb0HoNh58iV xLOhkc8EW1Ikvbi+/i+Dg6fvhkyMeYlA+FTVKE2RrVK3A7rpc+FzJHUxR0wTQ7QQ26t8 L2EaQEaUlrIPN0uaaIg3XDMhAKNjBJvO8Eea6E4VzoBpfKrX4OSVA4FK7j2bOxK6lK/H E4/tztiAvNCbQPn0euQIadpatwx8hSQCAS1/vzs89ylaAlw3oJekdbSEM5Fm92E+AwLm 6hoKbSPftzXTPPbgVF0j/C7FHTHfnxNNnOccSwEzcnySOyWOL8bIUJZfLr1m5oTSOXTu 9U0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681870505; x=1684462505; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=omaGeiilnWY8neqCu1aYblokWGcDA5y3QiHgOwpl4SY=; b=Tv3Sh31K+FMrskHgmoOil7eLs3m0AZ5nHrl4s/U5tDRnFuaGsPKgMwwSAJzzuae+Im MoiBGH2hhCuY62bG7UAH/+JC+MrU7xtomRUogtIxnWRGafPRfbNU+htY6Zbl1S1a+erf nDd+1OO77ECbgo2Bsd4uuwg2x+R4qxcPh7OsOpWt6V3t9DTQNlkGo559mcTVHsEwUoc6 S6QgrYh6dnkL5s0bel6munHMSgclv6tCNbngoujhfN5xy+pRduTaHmjWr9+aAJyqWuHd 4Jt3QVpgzScewEoQ8XPufakwhUvvgeVv96slpabhgD5+sUqR+8+uafAOBy3TB+jeUXGv YSZw== X-Gm-Message-State: AAQBX9c+NFGAF2b/zQ80SU4U7G+HINa/mzm+hyg+4hzCVMkGQ9A5AoMf QUNVCCejNE3fSqjdLVvbuT4mEQ== X-Google-Smtp-Source: AKy350Zy3gIP/wJlOTrxIJOZjD1BKAKhDNMPB17EIgaujgA65bwcNbe8U/3vRZImIHTIB+BoiThlzA== X-Received: by 2002:a05:6a00:44c6:b0:638:2493:1710 with SMTP id cv6-20020a056a0044c600b0063824931710mr16865100pfb.3.1681870505004; Tue, 18 Apr 2023 19:15:05 -0700 (PDT) Received: from [192.168.1.136] ([198.8.77.157]) by smtp.gmail.com with ESMTPSA id c18-20020aa78812000000b0063b73e69ea2sm7275709pfo.42.2023.04.18.19.15.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 18 Apr 2023 19:15:04 -0700 (PDT) Message-ID: <7dded5a8-32c1-e994-52a0-ce32011d5e6b@kernel.dk> Date: Tue, 18 Apr 2023 20:15:03 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: [PATCH] eventfd: support delayed wakeup for non-semaphore eventfd to reduce cpu utilization Content-Language: en-US To: Wen Yang , Alexander Viro , Christian Brauner Cc: Christoph Hellwig , Dylan Yudaken , David Woodhouse , Paolo Bonzini , Fu Wei , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org References: <817984a2-570c-cb23-4121-0d75005ebd4d@kernel.dk> From: Jens Axboe In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On 4/17/23 10:32?AM, Wen Yang wrote: > > ? 2023/4/17 22:38, Jens Axboe ??: >> On 4/16/23 5:31?AM, wenyang.linux@foxmail.com wrote: >>> From: Wen Yang >>> >>> For the NON SEMAPHORE eventfd, if it's counter has a nonzero value, >>> then a read(2) returns 8 bytes containing that value, and the counter's >>> value is reset to zero. Therefore, in the NON SEMAPHORE scenario, >>> N event_writes vs ONE event_read is possible. >>> >>> However, the current implementation wakes up the read thread immediately >>> in eventfd_write so that the cpu utilization increases unnecessarily. >>> >>> By adding a configurable delay after eventfd_write, these unnecessary >>> wakeup operations are avoided, thereby reducing cpu utilization. >> What's the real world use case of this, and what would the expected >> delay be there? With using a delayed work item for this, there's >> certainly a pretty wide grey zone in terms of delay where this would >> perform considerably worse than not doing any delayed wakeups at all. > > > Thanks for your comments. > > We have found that the CPU usage of the message middleware is high in > our environment, because sensor messages from MCU are very frequent > and constantly reported, possibly several hundred thousand times per > second. As a result, the message receiving thread is frequently > awakened to process short messages. > > The following is the simplified test code: > https://github.com/w-simon/tests/blob/master/src/test.c > > And the test code in this patch is further simplified. > > Finally, only a configuration item has been added here, allowing users > to make more choices. I think you'd have a higher chance of getting this in if the delay setting was per eventfd context, rather than a global thing. -- Jens Axboe