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

[Slawa Olhovchenkov]

On Wed, Sep 10, 2014 at 02:29:30PM -0400, John Baldwin wrote:

> > Application must change behaviour when reach limit (run GC, switch
> > algorithm and etc.).
> > But mmap of big data file for scaning and processing don't touch this
> > limit.
> > Must be mmap of some temoprary file touch this limit? I don't know.
> > Must be MAP_ANON touch this limit? I think yes.
> > How to make distinction of mmap data file for processing and mmap
> > temporary file for bypass this limit? I don't know.
> 
> Consider also mmap() of shm_open(SHM_ANON).

No, shm limited separatly. mmap of shm_open(SHM_ANON) don't need to adjust
this limit.

> > And again, most application don't handle correctly NULL of malloc().
> > I think this is depreciate of all.
> 
> This is true, but it seems Firefox might, and you could set RLIMIT_AS
> for Firefox in particular so it gets adequate feedback.  I do think if
> you can determine the "correct" value for RLIMIT_AS for Firefox that
> mmap(MAP_ANON) would fail and result in NULL from malloc().

I am do some time ago firefox limiting by ulimit -v, firefox just
crashing. Don't run GC or something else.

> > PS: question about jemalloc. How I can stop jemalloc to give back
> > memory to OS for some application?
> 
> You would have to hack pages_purge() in chunk_mmap.c to always return true and 
> not call madvise().

And got memory leak?
I am talk about change behaviour from periodic mmap and madvise memory
to only mmap when need and leave for future use when freed by
aplication. I think (may be wrong -- please correct) in some cases
mmap/madvise will be too often.