netdev - Re: [GIT PULL] Add support for epoll min wait time

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 10 Dec 2022 19:03:53 -0700
From:   Jens Axboe <axboe@...nel.dk>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     netdev <netdev@...r.kernel.org>,
        "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>
Subject: Re: [GIT PULL] Add support for epoll min wait time

On 12/10/22 12:26?PM, Linus Torvalds wrote:
> On Sat, Dec 10, 2022 at 10:51 AM Linus Torvalds
> <torvalds@...ux-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