Linux-kernel mailing list archive 1999-36,: Re: > 15,000 Simultaneous Connections

# Re: > 15,000 Simultaneous Connections

Rogier Wolff (R.E.Wolff@BitWizard.nl)
Tue, 7 Sep 1999 13:29:24 +0200 (MEST)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Mike Jagdis: "Re: > 15,000 Simultaneous Connections"
- Previous message: Alan Cox: "Re: PATCH: IDE PCI init cleanup"
- Next in thread: Mike Jagdis: "Re: > 15,000 Simultaneous Connections"
- Reply: Mike Jagdis: "Re: > 15,000 Simultaneous Connections"

Mike Jagdis wrote:
> On Mon, 6 Sep 1999, Jason Nordwick wrote:
>
> > Can you elaborate as to why it is not possible to remember interesting
> > descriptors in the blocking case?
>
> The kernel side can't remember fd sets because there is no way

I don't agree. See below.

> for it to figure out if the sets have changed between calls
> other than by scanning through them. Furthermore it has no way
> of knowing if an fd was checked in a previous call and no way
> of knowing if the descriptor changed in the meantime. So it has
> to check every interesting fd to see if it is ready or not.
> As a consequence of this stateless behaviour select and poll
> are defined to check and return the state of _every_ fd of
> interest when you might well have been happy to be told about
> the first n ready fds a hundred times sooner.

- Define a per-process setting "sloppy-select-is-ok" and you can
suddenly optimize at will.

But that's not neccesary. Handling the fdset isn't the problem.
Checking readyness of the thousands of filedescriptors is. So if you
keep a "this process is interested in these fds" set, and have the
driver that pushes data onto the fd callback that there is data, you
can have the list of ready-fds pre-built without having to check every
fd for readyness. If you want, you can check the read_fds bitarray
against a saved copy, to make sure that you immediatly catch
changes. I'm pretty sure that you can get away with only doing the
match every 100ms or something. If you have fd-returning calls
(accept, socket, open, pipe. any more?) mark the new fds as
interesting, you can catch those too without having to touch the
fdset.

If we indeed optimize select only to check every 100ms wether the
cached, remembered fdset is the same as the given fdset, we end up
with the situation where select may only notice a change in the fdset
a bit later. Applications shouldn't really care: The result is the
same as when data would've arrived a bit later.

We could let this mechanism kick in, when the system is under load.
Linus will probably reject this on a complexity argument.

I scanned the article taht someone mentioned. Implementing that API
sounds like a good idea too. (you register interest in an fd, and then
read the "event queue")

Roger.

    --
    ** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 **
    *-- BitWizard writes Linux device drivers for any device you may have! --*
    ------ Microsoft SELLS you Windows, Linux GIVES you the whole house ------

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

- Next message: Mike Jagdis: "Re: > 15,000 Simultaneous Connections"
- Previous message: Alan Cox: "Re: PATCH: IDE PCI init cleanup"
- Next in thread: Mike Jagdis: "Re: > 15,000 Simultaneous Connections"
- Reply: Mike Jagdis: "Re: > 15,000 Simultaneous Connections"