Thread (160 messages) 160 messages, 22 authors, 2006-08-22

Re: [take6 1/3] kevent: Core files.

From: Evgeniy Polyakov <hidden>
Date: 2006-08-11 07:28:26
Also in: netdev

On Fri, Aug 11, 2006 at 12:04:54AM -0700, Andrew Morton (akpm@osdl.org) wrote:
quoted
This area can be decreased down to 70mb by reducing amount of
information placed into the buffer (only user's data and flags) without
additional hints.
70MB is still very bad, naturally.
Actually I do not think that 4k events is a good choice - I expect people
will scale it to tens of thousands at least, so we definitely want not to
allow user to create way too many kevent fds.
There are other ways in which users can do this sort of thing - passing
fd's across sockets, allocating zillions of pagetables come to mind.  But
we don't want to add more.

Possible options:

- Add a new rlimit for the number of kevent fd's

- Add a new rlimit for the amount of kevent memory

- Add a new rlimit for the total amount of pinned kernel memory.  First
  user is kevent.
I think this rlimit and first one are the best choises.
- Account a kevent fd as being worth 100 regular fds, so the naughty user
  hits EMFILE early (ug).

A new rlimit is attractive, and they're easy to add.  Problem is, userspace
support is hard (I think).  afaik a standard Linux system doesn't have
global and per-user rlimit config files which are parsed and acted upon at
login.  That would make rlimits more useful.
As for now it is possible to use stack size rlimit for example.

-- 
	Evgeniy Polyakov
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help