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

[Evgeniy Polyakov <johnpol@2ka.mipt.ru>]

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 <johnpol@2ka.mipt.ru> wrote:
> 
> > On Thu, Aug 10, 2006 at 05:56:39PM -0700, Andrew Morton (akpm@osdl.org) wrote:
> > > > 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