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;
Date:   Mon, 7 Nov 2022 15:56:01 -0500
From:   Stefan Hajnoczi <stefanha@redhat.com>
To:     axboe@kernel.dk
Cc:     linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCHSET v3 0/5] Add support for epoll min_wait
Message-ID: <Y2lw4Qc1uI+Ep+2C@fedora>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
        protocol="application/pgp-signature"; boundary="XyBYP9056XoM9x6e"
Content-Disposition: inline
In-Reply-To: <20221030220203.31210-1-axboe@kernel.dk>
Precedence: bulk


--XyBYP9056XoM9x6e
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hi Jens,
NICs and storage controllers have interrupt mitigation/coalescing
mechanisms that are similar.

NVMe has an Aggregation Time (timeout) and an Aggregation Threshold
(counter) value. When a completion occurs, the device waits until the
timeout or until the completion counter value is reached.

If I've read the code correctly, min_wait is computed at the beginning
of epoll_wait(2). NVMe's Aggregation Time is computed from the first
completion.

It makes me wonder which approach is more useful for applications. With
the Aggregation Time approach applications can control how much extra
latency is added. What do you think about that approach?

Stefan

--XyBYP9056XoM9x6e
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhpWov9P5fNqsNXdanKSrs4Grc8gFAmNpcOEACgkQnKSrs4Gr
c8gDagf/YbI6zJoHxLPIL1cGSlayG7NOYya+8Vp+4dfv13V7/ZD6T/RQLJ0xhPhL
OZZ7TJ0zdOQL7a0J3RxUElcs06gIh7IHupL0YvX9ng0mVNl8DwkfsuLWdxj5Z2x/
gLD1YjCPHHAEwzHOcma7QR1I36SfxJhXSiyCUNhB3VF4jl9EZV2LIrA1fEUD4MBY
PNqILWWv81tm93jAFe1JrT/Ak20psPMXRIBfIkWkZfeH4totmbcUEoZLgV8HS4kF
kEodTyZGwS6kUt7512BC/CDXaiMi3XinLwjqJ42vq+jIHWxEfjwcEMa7KJpL6dg5
ULilMUkNtaXoeqzicuOv2m+qm3TqxQ==
=lz3z
-----END PGP SIGNATURE-----

--XyBYP9056XoM9x6e--