lkml.org 
[lkml]   [2006]   [Aug]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [take6 1/3] kevent: Core files.
    On Fri, 11 Aug 2006 10:30:21 +0400
    Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote:

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

    70MB is still very bad, naturally.

    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.

    - 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.
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-08-11 09:07    [W:0.024 / U:0.336 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site