Re: Jailed sysvipc implementation.

From: Pawel Jakub Dawidek (nick_at_garage.freebsd.pl)
Date: 06/25/03

  • Next message: Dmitry Sivachenko: "Re: Jailed sysvipc implementation." 
    Date: Wed, 25 Jun 2003 17:31:53 +0200
To: Dmitry Sivachenko <demon@FreeBSD.org>

    On Wed, Jun 25, 2003 at 07:21:19PM +0400, Dmitry Sivachenko wrote:
    +> > +> > But you got still *one* memory zones for every jail and main host.
    +> > +>
    +> > +> Yes, that is exactly what I want.
    +> > +> This is similar to separate IP stack for each jail: this is more powerful
    +> > +> solution, but more expensive (uses more kernel memory).
    +> >
    +> > But note that my implementation allocates memory "on demand".
    +>
    +> This is part of the problem: with single memory zone for all jails,
    +> less memory is allocated. With private memory zones, if m jails use IPC,
    +> you need to allocate m*M kbytes (for some value of M you consider
    +> sufficient for one jail).
    +>
    +> With one memory zone for all jails, it is enough to allocate N kbytes where
    +> M < N < m*M, because every jail will not use all M kbytes at the same time.

    Of course, but please. We could start wondering if struct prison in every
    ucred struct don't consume to much memory. Of course we allocate more memory,
    but if we want to run for example two instants of postgresql in two
    diffrent jails?

    But ok, it will be good compromise to add sysctl security.jail.privipc IMHO.
    So we could turn this feature on if it is needed. What is your opinion? 

    -- 
Pawel Jakub Dawidek                       pawel@dawidek.net
UNIX Systems Programmer/Administrator     http://garage.freebsd.pl
Am I Evil? Yes, I Am!                     http://cerber.sourceforge.net

  • Next message: Dmitry Sivachenko: "Re: Jailed sysvipc implementation."

    Relevant Pages

    • Tru64 issues with Infinite limits
      ... An automated test in my nightly build was failing due to Out of Memory ... Cannot allocate block 146 ...
      (comp.unix.tru64)
    • Re: run-time vs compile-time
      ... > offset related to some location (like stack base) somewhere. ... > offset from heap to pi. ... When you allocate an int on the heap, it is allocated at address 1. ... application has a given amount of memory it can use as it wishes. ...
      (alt.comp.lang.learn.c-cpp)
    • Re: run-time vs compile-time
      ... > offset related to some location (like stack base) somewhere. ... > offset from heap to pi. ... When you allocate an int on the heap, it is allocated at address 1. ... application has a given amount of memory it can use as it wishes. ...
      (comp.lang.cpp)
    • Re: SBCL performance on OS X
      ... > than C at allocating memory. ... > OpenMCL on the powerbook is an order of magnitude slower than SBCL ... comparison with the lisp implementation of your experiment terribly ... allocate an extra two-word structure to store it in, ...
      (comp.lang.lisp)
    • Re: Sharing memory between kernelspace and userspace
      ... deallocate, on a totally dynamic basis, userspace ... Let userspace allocate shared memory visible to multiple ... and pass that into the kernel for it to write to. ...
      (Linux-Kernel)