On Tue, Feb 19, 2008 at 06:58:08PM +0000, Robert Watson wrote: > > On Tue, 19 Feb 2008, Jason Evans wrote: > > >>As sbrk() is less preferable because of framentation and race conditions, > >>why not to create mmap() flag MMAP_DSS to check RLIMIT_DATA and to use it > >>in malloc(3) ? > > > >There has been general agreement among the people I've discussed this > >issue with that the correct solution is to add a separate resource limit > >for anonymously mapped memory, which would provide capabilities similar to > >what your suggestion would provide. > > Konstantine has updated his patches and reported on them in the recent > status report: > > http://www.freebsd.org/news/status/report-2007-10-2007-12.html#VM-Overcommit > > Here's the main site for information on the patch: > > http://people.freebsd.org/~kib/overcommit/ > > He describes a per-uid limit, but I think it might also be useful to have a > per-process limit tht can also be enforced, although possibly not by > default, so that protecting applications from each other doesn't require > creating separate users for them. Yes, per-process limits can be added too, although it would require some additional thinking. The persistent objects backed by anonymous memory, like SysV shm or shm_open(2) handles would be billed for the creator only. It is not immediately obvious whether it is right or not. Anyway, I want to get the review first, before doing further modifications.
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:27 UTC