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

From: Bill Wendling (wendling@ganymede.isdn.uiuc.edu)
Date: Tue Jan 18 2000 - 13:22:20 EST


Also sprach Tigran Aivazian:
}
} 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
} pollfd));
} if (fds[nchunks] == NULL) {
} int k;
}
} printk(KERN_ERR "poll(): can't kmalloc a
} chunk\n");
} for (k = nchunks-1; k > 0; k--)
} kfree(fds[k]);
} goto out;
} }
} nchunks++;
} nleft -= POLL_PER_CHUNK;
} }
} if (nleft) {
} fds[nchunks] = kmalloc(nleft * sizeof(struct pollfd));
} nchunks++;
} }
}
} 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?
}
I tried something similar with linked-lists...It "looked" fine to me, but
caused polling to become...strange...It would continually poll on some
fds over and over. I could find no real explanation for it, so I dropped
that line.

Your solution would be nice, however you are introducing loops which
could be a small performance hit.

-- 
|| Bill Wendling			wendling@ganymede.isdn.uiuc.edu

- 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/



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