Messages in this thread | | | Date | Fri, 28 Mar 1997 19:18:17 -0500 (EST) | From | Jon Lewis <> | Subject | Re: >256 fd patch... |
| |
On Wed, 26 Mar 1997, James L. McGill wrote:
> >> Do you see a lot of "Couldn't get a free page" and "Out of Memory" with this? > >I am getting a lot of "cannot fork" messages and: > > I fear this issue is now going to vanish back into the black hole. > Thanks for working on it Oskar. I don't see anything in select.c > that would lead to this, but then, I'm no mechanic.
My guess is that the patches that do a kmalloc for nearly all selects are allocating large amounts of RAM that will never be used. I'm using Michael O'Reilly's patch on my IRC server and SMP test box, and on the IRC server, the ircd does _LOTS_ of select all with the full number of fd's it's compiled to use (1000 in our case). I don't know enough to know if it has a good reason for this, or if the ircd code is brain damaged.
From what I can gather reading the kernel patch, O'Reilly's patch allocates a chunk of memory based on the size of NR_OPEN no matter how many fd's select was given. I suppose this is required for the caching...but what would happen if the caching was thrown out, and the memory allocations were based on the n in "sys_select(int n..." rather than NR_OPEN?...or if n is some small number, allocate the memory the old way from the stack rather than kmalloc?
Is the solution to the frequent "Couldn't get a free page" problem a modification to the kernel patches or a tidying up of code in such things as the ircd?
------------------------------------------------------------------ Jon Lewis <jlewis@fdt.net> | Unsolicited commercial e-mail will Network Administrator | be proof-read for $199/hr. ________Finger jlewis@inorganic5.fdt.net for PGP public key_______
| |