svn commit: r270759 - in head/sys: cddl/compat/opensolaris/kern cddl/compat/opensolaris/sys cddl/contrib/opensolaris/uts/common/fs/zfs vm

[John Baldwin]

On Tuesday, September 09, 2014 02:25:18 PM Slawa Olhovchenkov wrote:
> On Mon, Sep 08, 2014 at 11:17:51AM -0400, John Baldwin wrote:
> > On Sunday, September 07, 2014 04:56:49 PM Slawa Olhovchenkov wrote:
> > > PS: very bad that 'data limit' don't anymore reflect application
> > > memory consumer. and very small application can adapt to 'no memory'
> > > from system.
> > 
> > You can use RLIMIT_AS instead of RLIMIT_DATA.  jemalloc can also be
> > configured to use sbrk(), though I think there's no way to prevent it
> > from falling back to mmap(MAP_ANON) if sbrk() fails.
> 
> Formally you are right. Realy this is scorn. And I don't know how
> rightly. May be account in RLIMIT_DATA MAP_ANON? Anyway firefox don't
> run GC if malloc fail and this is bad.

It was not intended as scorn, simply stating what options you have
available as alternatives to what you are asking for.  The Firefox
behavior certainly seems unfortunate. :(  However, using RLIMIT_AS
for that should work as the mmap() call malloc() makes will fail
causing malloc() to fail.  However, you need RLIMIT_AS to be a bit
larger than what you would set RLIMIT_DATA to.

As to having MAP_ANON honor RLIMIT_DATA, I'm not sure how well that
would work.  I assume that was discussed as an option in the previous
threads on the topic of RLIMIT_DATA being useless with jemalloc.
I don't recall it though.  Perhaps Alan can speak to whether or not
that is a good idea?

-- 
John Baldwin