On Thu, Aug 10, 2006 at 11:23:40PM -0700, Andrew Morton (akpm@osdl.org) wrote:

On Fri, 11 Aug 2006 10:15:35 +0400
Evgeniy Polyakov [off-list ref] wrote:

quoted

On Thu, Aug 10, 2006 at 05:56:39PM -0700, Andrew Morton (akpm@osdl.org) wrote:

quoted

quoted

Per kevent fd.
I have some ideas about better mmap ring implementation, which would
dinamically grow it's buffer when events are added and reuse the same
place for next events, but there are some nitpics unresolved yet.
Let's not see there in next releases (no merge of course), until better 
solution is ready. I will change that area when other things are ready.

This is not a problem with the mmap interface per-se.  If the proposed
event code permits each user to pin 160MB of kernel memory then that would
be a serious problem.

The main disadvantage is that all memory is allocated on the start even
if it will not be used later. I think dynamic grow is appropriate
solution, since user will have that memory used anyway, since kevents
are allocated, just part of them will be allocated from possibly 
mmaped memory.

But the worst-case remains the same, doesn't it?  160MB of pinned kernel
memory per user?

Yes. And now I think dynamic growing is not a good solution, since user
can not know when he must call mmap() again to get additional pages
(although I have some hacks to "dynamically" replace previously mmapped
pages with new ones).

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.

-- 
	Evgeniy Polyakov