Re: [Patch] Polling on more than 16000 file descriptors

From: Tigran Aivazian (tigran@sco.COM)
Date: Tue Jan 18 2000 - 10:15:08 EST

On Tue, 18 Jan 2000, Alan Cox wrote:

> > I just noticed your patch but why do you use vmalloc() above just 1 page
> > and not the kmalloc()'s limit of 128K? Surely below 128K kmalloc() is
> > faster than vmalloc()? (I know ipc_alloc() does the same but why?).
> 128K kmallocs often fail. Probably something like a 32K kmalloc limit
> with vmalloc if the kmalloc fails or >32K ?

I know, which is why I said (to you in private) 256K is a bad idea
(fragmentation in a few minutes after using the box).

But, even better than your idea (dare I say :) is to have chunked
allocation and using kmalloc() all the time, something like (roughly):

#define POLL_PER_CHUNK 16000
#define POLL_NCHUNKS 8

struct pollfd * fds[POLL_NCHUNKS];

nchunks = 0;
        nleft = nfds;
        while (nleft > POLL_PER_CHUNK) {
                fds[nchunks] = kmalloc(POLL_PER_CHUNK * sizeof(struct
                if (fds[nchunks] == NULL) {
                        int k;

                        printk(KERN_ERR "poll(): can't kmalloc a
                        for (k = nchunks-1; k > 0; k--)
                        goto out;
                nleft -= POLL_PER_CHUNK;
        if (nleft) {
                fds[nchunks] = kmalloc(nleft * sizeof(struct pollfd));

but do_poll() will need to be changed to accomodate passing new type of
arguments (and number of full chunks) so I intend to implement this in the
evening at home, if you guys agree with the approach in principle?

Tigran A. Aivazian |
Escalations Research Group | tel: +44-(0)1923-813796
Santa Cruz Operation Ltd |

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

This archive was generated by hypermail 2b29 : Sun Jan 23 2000 - 21:00:18 EST