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 88A66C6FD18 for ; Wed, 19 Apr 2023 09:12:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232521AbjDSJMg (ORCPT ); Wed, 19 Apr 2023 05:12:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45466 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230289AbjDSJMe (ORCPT ); Wed, 19 Apr 2023 05:12:34 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CEA0B107; Wed, 19 Apr 2023 02:12:32 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 6D010616F2; Wed, 19 Apr 2023 09:12:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 80449C433EF; Wed, 19 Apr 2023 09:12:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1681895551; bh=6YUk6AAUM3ORtZrVrup0K5gL81Envy2abVP09sfpCtM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=QcNT5UtHpG5io2IFoZ/G9pv2UUsfH2QQ/hC3mndggqwowNMEe+Gpb9i6hJO6ZQ9At z3plzTA9Lme0bPCMpxtKRU7uAAFLVx4fuy1ptVuYrCdFHzN8jLA16+TZQyuab7I6/u /aeFTe52sGK6zM7lQJZrfRAQOuJhxFlbw3ciP6ncyT+XW9XsuLZioZXA7CBcxcYveD 3w996/ZwzUPCH+VHOaPAe6ZjG0261i5jT/wBFMYXMBrLDzs44mia4hUuW0dpCWR7OB k2Zm4L1Vo1xIJkgHgOo6JbZKlPuQbc03OTcyvntPC1MNofXLCRMdafYR7zRKOWiglN nr/TJXLxohPQA== Date: Wed, 19 Apr 2023 11:12:25 +0200 From: Christian Brauner To: Jens Axboe Cc: Wen Yang , Alexander Viro , Christoph Hellwig , Dylan Yudaken , David Woodhouse , Paolo Bonzini , Fu Wei , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] eventfd: support delayed wakeup for non-semaphore eventfd to reduce cpu utilization Message-ID: <20230419-blinzeln-sortieren-343826ee30ce@brauner> References: <817984a2-570c-cb23-4121-0d75005ebd4d@kernel.dk> <7dded5a8-32c1-e994-52a0-ce32011d5e6b@kernel.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <7dded5a8-32c1-e994-52a0-ce32011d5e6b@kernel.dk> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 18, 2023 at 08:15:03PM -0600, Jens Axboe wrote: > 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. That patch seems really weird. Is that an established paradigm to address problems like this through a configured wakeup delay? Because naively this looks like a pretty brutal hack.