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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0AB4FC001B0 for ; Mon, 17 Jul 2023 19:08:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 846536B007B; Mon, 17 Jul 2023 15:08:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7CF658D0002; Mon, 17 Jul 2023 15:08:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 622948D0001; Mon, 17 Jul 2023 15:08:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 4D3546B007B for ; Mon, 17 Jul 2023 15:08:40 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 10F6FA0520 for ; Mon, 17 Jul 2023 19:08:40 +0000 (UTC) X-FDA: 81022040400.11.6077B3C Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf15.hostedemail.com (Postfix) with ESMTP id C3525A001E for ; Mon, 17 Jul 2023 19:08:36 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=GzDhDbaq; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf15.hostedemail.com: domain of alex.williamson@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=alex.williamson@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1689620916; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=qHz5V5lwxUlduWSVUZLKGbl1lWEkFIrU74CIU+5Jsd8=; b=J8MF4QAwX2Vf8bqeZAzCfSslpnd5xTKgrn+J4f1aSAWauX48KC6ZmGRoQhmjp+8k9g0a97 MAofUjqtFrgtblgEo0TcLpqRUgWJzcpmUKBveThGAf/sslxZfaJBi/Jj+//QFIY4jqhtfm GFBpP4uGMd1+09t4r1wVhEAb9pI7Fwg= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=GzDhDbaq; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf15.hostedemail.com: domain of alex.williamson@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=alex.williamson@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1689620916; a=rsa-sha256; cv=none; b=kGfuI3bLPoJrRQ9tWjZ+6vw7TR5PZoBkH0jLoqCuNLYuBBOqi1HFpJkQW1OCkGKFYEjj9N f+mxUshDMVPvYo7/1MFeJTeMavBECRUQ5wZksvZacpUx/xcSphc/WV+WgJMkzNRZoThXLj fxbqwKsGaUsOxIylkjZy58UgqmtlrrM= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1689620916; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=qHz5V5lwxUlduWSVUZLKGbl1lWEkFIrU74CIU+5Jsd8=; b=GzDhDbaqmhUIrUx/hs9lggdhALbPT6ujFbRvFnYTPdFWYpprz1v1wZM80teH6EYOGN8s42 A29slQUAhFX4M6A5BWJl7mV7YKvIV7CVTLx8kw5Hg2BBpj9eTD5bgyTIuatAl959AC1aoa UXN0vUn1CV5OvKptQ3AgecLmpYw2L7U= Received: from mail-il1-f198.google.com (mail-il1-f198.google.com [209.85.166.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-477-IzQ1JfPcPy20Tr64U5UvmQ-1; Mon, 17 Jul 2023 15:08:35 -0400 X-MC-Unique: IzQ1JfPcPy20Tr64U5UvmQ-1 Received: by mail-il1-f198.google.com with SMTP id e9e14a558f8ab-34610c52cf8so30600825ab.0 for ; Mon, 17 Jul 2023 12:08:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689620914; x=1692212914; h=content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=Ir1J/k3wLKNYp7LI2ijvFBF6ZKrDfOA6Drq2a2Jon50=; b=LmfDFblhAe6FqrFBPzJISEyNcDqTzLZWgLJSsL4bG0BVt9XutsfwdLWN64tv6OYa3O gClYL3uklF1bMt1Gma9xtkpaf7l0yqG1VWF/i9kZH3y4d02KbvxomWRaE6hi01CeUJ2g DTyQHs25icbLqDX/ns8VzjaV35I14Z3D7N4DRR12MGp73TG1uLJGMXBRvk/y+24ShgsZ y51WoJZWGb0hmnkHtuef+nUOyxQpBw+R5/CYzfUM8TC3Jv+Jaw6O5zbtVYbIbhBt38vH SUhXsnxk3P3t6lg036sHyx0OOpyE/b7xszDXEWR5F1MDTcwG4nn9l3FXmJpBFWegaqEo GhGw== X-Gm-Message-State: ABy/qLZpgtfWbZ7QnICjEOeIfDuvn7LI6goWbvDU/bSPZcgd0VGpAjW+ v/0jdw4ay//4FBzZvp6PTb/5bTFpbIjcTwS6BJQVLNy+b3j8gvVwEpSJ98BBSrlOukKNlX8xZIH LHFHISn/UQRY= X-Received: by 2002:a05:6e02:1a8b:b0:348:8542:a673 with SMTP id k11-20020a056e021a8b00b003488542a673mr578077ilv.22.1689620914127; Mon, 17 Jul 2023 12:08:34 -0700 (PDT) X-Google-Smtp-Source: APBJJlH8IAKDk/Qq0r0DbEq84CfbH5y70uroq/83Nyu0gFtjM6u4GlatJgupAE/Bg/5ujaAlXs4PMg== X-Received: by 2002:a05:6e02:1a8b:b0:348:8542:a673 with SMTP id k11-20020a056e021a8b00b003488542a673mr578040ilv.22.1689620913830; Mon, 17 Jul 2023 12:08:33 -0700 (PDT) Received: from redhat.com ([38.15.36.239]) by smtp.gmail.com with ESMTPSA id o9-20020a92dac9000000b003460b456030sm129837ilq.60.2023.07.17.12.08.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 17 Jul 2023 12:08:33 -0700 (PDT) Date: Mon, 17 Jul 2023 13:08:31 -0600 From: Alex Williamson To: Grzegorz Jaszczyk Cc: Christian Brauner , linux-fsdevel@vger.kernel.org, linux-aio@kvack.org, linux-usb@vger.kernel.org, Matthew Rosato , Paul Durrant , Tom Rix , Jason Wang , dri-devel@lists.freedesktop.org, Michal Hocko , linux-mm@kvack.org, Kirti Wankhede , Paolo Bonzini , Jens Axboe , Vineeth Vijayan , Diana Craciun , Alexander Gordeev , Xuan Zhuo , Shakeel Butt , Vasily Gorbik , Leon Romanovsky , Harald Freudenberger , Fei Li , x86@kernel.org, Roman Gushchin , Halil Pasic , Jason Gunthorpe , Ingo Molnar , intel-gfx@lists.freedesktop.org, Christian Borntraeger , linux-fpga@vger.kernel.org, Zhi Wang , Wu Hao , Jason Herne , Eric Farman , Dave Hansen , Andrew Donnellan , Arnd Bergmann , linux-s390@vger.kernel.org, Heiko Carstens , Johannes Weiner , linuxppc-dev@lists.ozlabs.org, Eric Auger , Borislav Petkov , kvm@vger.kernel.org, Rodrigo Vivi , cgroups@vger.kernel.org, Thomas Gleixner , virtualization@lists.linux-foundation.org, intel-gvt-dev@lists.freedesktop.org, io-uring@vger.kernel.org, netdev@vger.kernel.org, Tony Krowiak , Tvrtko Ursulin , Pavel Begunkov , Sean Christopherson , Oded Gabbay , Muchun Song , Peter Oberparleiter , linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org, Benjamin LaHaise , "Michael S. Tsirkin" , Sven Schnelle , Greg Kroah-Hartman , Frederic Barrat , Moritz Fischer , Vitaly Kuznetsov , David Woodhouse , Xu Yilun , Dominik Behr , Marcin Wojtas Subject: Re: [PATCH 0/2] eventfd: simplify signal helpers Message-ID: <20230717130831.0f18381a.alex.williamson@redhat.com> In-Reply-To: References: <20230630155936.3015595-1-jaz@semihalf.com> <20230714-gauner-unsolidarisch-fc51f96c61e8@brauner> Organization: Red Hat MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: C3525A001E X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: 6msrkciq8tqqbxgwz8a46t1qkeuijqpp X-HE-Tag: 1689620916-77713 X-HE-Meta: U2FsdGVkX19nktL5A6HBaqdwD9dQ8SCZYFVwTL6v2VLi84k8fn88c6C3OBAlQfzXttJOOVSGWqHw0/ZpdC/7LJWf0tS/cbJnjR7iOjvi/8IpZqMnfN/YXr1QM6k5bNufHPcEXIszph9z6EZ1oic0wAT6TkC718tgyAgIYDEzZRz2a4Qgx3lH60JG11d5Od4x/cpt21nvStUE7RO5+/BAIvFrOP8ouIXf4pki661AoU+HCju/b016YhyLtTkn3yWMvXMeJ5t+wVeEQ842JjxFNgl39iSDJPJ4/CukAUVWSEA5H0TFn6PzzJ3+sHqmwruzYgqeLNFr6sjp8wLnGeO0mSPs58sHjRqvA/M4hPAQeaL9Ersn4tDC6Djz5K+uNolrb89oPcx1D/+X7vdEXwkNT8FiITaRAwGGrQ9h2eDwHPu+jJ/vPmgA18GatT3AcdSeNefrIqU/Arm5nm9RJ+rirFzEP+LOFpY1+2QUe+Tf/yHVxn7EVStWPUt0d0AiozFAq8pp/dx6eQ1m6uFM5FIauwU6S9Fx9w+FLdrb0VbUJ2VGhEkkG7g7F0V8AHghoQ3X1gx7eZZTUi6Yw4WmrEzyE0j/VWk/6QQUbV7Ti7CvIMoOQcJ+s5Oun4fGDbdo5Jn17YfUIq5OojWg7KUdnrMdyAGM3z0tGdmwBFFHud0dw79TQ1g3BeVt1DfGUC94W7WvqWYTwiy+d8vpaBUxmnk7qj4HU/g7+A5Af+5IVRIYYt2Rjf1+V9GKoKnBWPhaq8D8AbIdd/JBfYvU46wxl3YKqoWkQsC1gKI/pXbC8MzVK/NIaAXuI17vkvsDlnOny3Ny4K6uCfI/as3Yg5I4n3qODTuotAHQ4j17Ec2KpZL+c/WlU186H/yNAVe7VGrWawkuEXNEaWph2FgpYmRHTTwjJSEAdPz30gyT7mOmTVkO/kTOyNnM8yGQtcfJqSHkspR9UWhZoJ3Y3Io03imqaKd b9wA5hfm KMNrgDo1NPu6XgYpWB0nhR9n4YN3s7U7dba39cLQ+qBeyoWXuKHa6COQdy6nzydno9w/5TXkrCOiSdN4gxYPOnHupFakCUJnnJs0xydI+bAD8JjyrJtgJglk8I95cYqmDk7Ak/AoExvIijvglgaO7D1lb5h4jYvfXH/RwhFX8pSmG03uQxG9E0CjWvA7oQgiewDTpf//Ix2st6Fi+qvrQc169U+4M8jHhJZ2NUqzMnQ64IT7jNf1GPRZgErFqdLlEVLFWiIL2qUghV1gh1tlFZELcQsQC+YgGcR/3s15xQqhBaZZaBkjNFjAOrCD+JkT0ECFg9egFSBzwx9lf7aAqVPDz5/H6S25+LcskCh6r75wDqM3GXt9Ml/so8UOIDtDXHVh/zyMFoA7+HqFYKcZdntv6qlnan/UpjkIJ6JJAGpB3KY4D1C9TC13JevYt8xGy1pyaCS8qMrTwvFIK0fuvy2tLYGeH2j+Jw7P1usH5N5CpyBmKiPOqCTrC7mt6kv5lYM7dT1wk3cGLT9w4cvR8gbONZvnbvTrxKJ+G1TWGOVX3RzJ4WjS5ZnrJnM1Khi/DGe454hF6+WBl0NZY8FV4QIgang== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, 17 Jul 2023 10:29:34 +0200 Grzegorz Jaszczyk wrote: > pt., 14 lip 2023 o 09:05 Christian Brauner napisa=C5= =82(a): > > > > On Thu, Jul 13, 2023 at 11:10:54AM -0600, Alex Williamson wrote: =20 > > > On Thu, 13 Jul 2023 12:05:36 +0200 > > > Christian Brauner wrote: > > > =20 > > > > Hey everyone, > > > > > > > > This simplifies the eventfd_signal() and eventfd_signal_mask() help= ers > > > > by removing the count argument which is effectively unused. =20 > > > > > > We have a patch under review which does in fact make use of the > > > signaling value: > > > > > > https://lore.kernel.org/all/20230630155936.3015595-1-jaz@semihalf.com= / =20 > > > > Huh, thanks for the link. > > > > Quoting from > > https://patchwork.kernel.org/project/kvm/patch/20230307220553.631069-1-= jaz@semihalf.com/#25266856 > > =20 > > > Reading an eventfd returns an 8-byte value, we generally only use it > > > as a counter, but it's been discussed previously and IIRC, it's possi= ble > > > to use that value as a notification value. =20 > > > > So the goal is to pipe a specific value through eventfd? But it is > > explicitly a counter. The whole thing is written around a counter and > > each write and signal adds to the counter. > > > > The consequences are pretty well described in the cover letter of > > v6 https://lore.kernel.org/all/20230630155936.3015595-1-jaz@semihalf.co= m/ > > =20 > > > Since the eventfd counter is used as ACPI notification value > > > placeholder, the eventfd signaling needs to be serialized in order to > > > not end up with notification values being coalesced. Therefore ACPI > > > notification values are buffered and signalized one by one, when the > > > previous notification value has been consumed. =20 > > > > But isn't this a good indication that you really don't want an eventfd > > but something that's explicitly designed to associate specific data wit= h > > a notification? Using eventfd in that manner requires serialization, > > buffering, and enforces ordering. What would that mechanism be? We've been iterating on getting the serialization and buffering correct, but I don't know of another means that combines the notification with a value, so we'd likely end up with an eventfd only for notification and a separate ring buffer for notification values. As this series demonstrates, the current in-kernel users only increment the counter and most userspace likely discards the counter value, which makes the counter largely a waste. While perhaps unconventional, there's no requirement that the counter may only be incremented by one, nor any restriction that I see in how userspace must interpret the counter value. As I understand the ACPI notification proposal that Grzegorz links below, a notification with an interpreted value allows for a more direct userspace implementation when dealing with a series of discrete notification with value events. Thanks, Alex > > I have no skin in the game aside from having to drop this conversion > > which I'm fine to do if there are actually users for this btu really, > > that looks a lot like abusing an api that really wasn't designed for > > this. =20 >=20 > https://patchwork.kernel.org/project/kvm/patch/20230307220553.631069-1-ja= z@semihalf.com/ > was posted at the beginig of March and one of the main things we've > discussed was the mechanism for propagating acpi notification value. > We've endup with eventfd as the best mechanism and have actually been > using it from v2. I really do not want to waste this effort, I think > we are quite advanced with v6 now. Additionally we didn't actually > modify any part of eventfd support that was in place, we only used it > in a specific (and discussed beforehand) way.