From: Jens Axboe <axboe@kernel.dk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: netdev <netdev@vger.kernel.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: [GIT PULL] Add support for epoll min wait time
Date: Sat, 10 Dec 2022 19:03:53 -0700 [thread overview]
Message-ID: <e48b3a8f-eabd-7c63-79cc-c58fb91aa990@kernel.dk> (raw)
In-Reply-To: <CAHk-=wiT67DtHF8dSu8nJpA7h+T4jBxfAuR7rcp0iLpKfvF=tw@mail.gmail.com>
On 12/10/22 12:26?PM, Linus Torvalds wrote:
> On Sat, Dec 10, 2022 at 10:51 AM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>>
>> Now, maybe there is some reason why the tty like VMIN/VTIME just isn't
>> relevant, but I do think that people have successfully used VMIN/VTIME
>> for long enough that it should be at least given some thought.
>
> Side note: another thing the tty layer model does is to make this be a
> per-tty thing.
>
> That's actually noticeable in regular 'poll()/select()' usage, so it
> has interesting semantics: if VTIME is 0 (ie there is no inter-event
> timeout), then poll/select will return "readable" only once you hit
> VMIN characters.
>
> Maybe this isn't relevant for the epoll() situation, but it might be
> worth thinking about.
It really has to be per wait-index for epoll, which is the epoll
context...
> It's most definitely not obvious that any epoll() timeout should be
> the same for different file descriptors.
Certainly not, and that's where the syscall vs epoll context specific
discussion comes in. But I don't think you'll find many use cases where
this isn't a per epoll context kind of thing for networking.
Applications just don't mix and match like that and have wildly
different file descriptors in there. It's generally tens to hundreds of
thousands of sockets.
> Willy already mentioned "urgent file descriptors", and making these
> things be per-fd would very naturally solve that whole situation too.
>
> Again: I don't want to in any way force a "tty-like" solution. I'm
> just saying that this kind of thing does have a long history, and I do
> get the feeling that the tty solution is the more flexible one.
>
> And while the tty model is "per tty" (it's obviously hidden in the
> termios structure), any epoll equivalent would have to be different
> (presumably per-event or something).
>
> So I'm also not advocating some 1:1 equivalence, just bringing up the
> whole "ttys do this similar thing but they seem to have a more
> flexible model".
Maybe this can be per-fd down the line when we have something like
urgent file descriptors. My hope there would be that we just use
io_uring for that, this series is very much just about eeking out some
more performance from it until that transition can be made anyway. I
don't have a lot of vested personal interest in improving epoll outside
of that, but it is a really big win that would be silly to throw away
while other more long term transitions are happening.
--
Jens Axboe
next prev parent reply other threads:[~2022-12-11 2:04 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-10 15:36 [GIT PULL] Add support for epoll min wait time Jens Axboe
2022-12-10 15:58 ` Willy Tarreau
2022-12-10 16:05 ` Jens Axboe
2022-12-10 16:17 ` Willy Tarreau
2022-12-10 16:23 ` Jens Axboe
2022-12-10 18:51 ` Linus Torvalds
2022-12-10 19:26 ` Linus Torvalds
2022-12-11 2:03 ` Jens Axboe [this message]
2022-12-11 1:58 ` Jens Axboe
2022-12-11 2:20 ` Jens Axboe
2022-12-11 2:31 ` Jens Axboe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e48b3a8f-eabd-7c63-79cc-c58fb91aa990@kernel.dk \
--to=axboe@kernel.dk \
--cc=linux-fsdevel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox