lkml.org 
[lkml]   [2000]   [Jan]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch-2.3.40-pre6] nfds limit for poll() raised to 131 million (is that enough?)
Also sprach Tigran Aivazian:
} Hi,
}
} On Wed, 19 Jan 2000, Bill Wendling wrote:
} > struct pollfd **fds;
} >
} > /* [...] */
} >
} > fds = (struct pollfd **)kmalloc(
} > (1 + (nfds - 1) / POLL_PER_CHUNK) * sizeof(struct pollfd *),
} > GFP_KERNEL);
}
} ok, fine, but the above still has a limit of the argument to kmalloc <128K
} which is around 131 million descriptors - I suppose that ought to be
} enough for everybody... This is a theoretical limit as kmalloc()s of
} individual chunks will start failing much sooner (when the total causes
} fragmentation high enough for a single chunk allocation to fail).
}
} Thanks for your suggestion - here is the **fds implementation:
}
} http://www.ocston.org/~tigran/patches/pollfix2.patch
}
} Does Alan have any preference or are we all working in the wrong direction
} and he prefers kmalloc/vmalloc split (or some other) idea?
}
Yeah, I thought of that afterwards. You could, of course, use vmalloc
with the appropriate vfree and {un}lock_kernel calls...

Be careful when you say things a la B. Gates (Re: X ought to be enough
for everybody)...They tend to come back and haunt you :).

Cheers!

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

\
 
 \ /
  Last update: 2005-03-22 13:56    [W:0.118 / U:0.392 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site