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;
From:   Jens Axboe <axboe@kernel.dk>
To:     linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Cc:     soheil@google.com, willemdebruijn.kernel@gmail.com,
        stefanha@redhat.com
Subject: [PATCHSET v4 0/7] Add support for epoll min_wait
Date:   Thu,  1 Dec 2022 11:11:49 -0700
Message-Id: <20221201181156.848373-1-axboe@kernel.dk>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: bulk

Hi,

tldr - we saw a 6-7% CPU reduction with this patch. See patch 6 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 6, patches 1-5 are really
just prep patches or cleanups, and patch 7 adds the API to set min_wait.

I've decided against adding a syscall for this due to the following
reasons:

1) We, Meta, don't need the syscall variant.
2) It's unclear how best to do a clean syscall interface for this. We're
   already out of arguments with the pwait/pwait2 variants.

With the splitting of the API into a separate patch, anyone who wishes
to have/use a syscall interface would be tasked with doing that
themselves.

No real changes in this release, just minor tweaks. Would appreciate
some review on this so we can get it moving forward. I obviously can't
start real deployments at Meta before I have the API upstream, or at
least queued for upstream. So we're currently stuck in limbo with this.

Also available here:

https://git.kernel.dk/cgit/linux-block/log/?h=epoll-min_ts

Since v3:
- Split the ctl addition into separate patch
- Gate setup of min_wait on !ewq.timed_out
- Add comment on calling ctl with wait == 0 is a no-op

-- 
Jens Axboe