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