From owner-svn-src-head@FreeBSD.ORG Wed Sep 10 19:29:29 2014 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 37E487B5; Wed, 10 Sep 2014 19:29:29 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D95C9121; Wed, 10 Sep 2014 19:29:28 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XRnZx-000CHD-Fa; Wed, 10 Sep 2014 23:29:21 +0400 Date: Wed, 10 Sep 2014 23:29:21 +0400 From: Slawa Olhovchenkov To: John Baldwin Subject: Re: svn commit: r270759 - in head/sys: cddl/compat/opensolaris/kern cddl/compat/opensolaris/sys cddl/contrib/opensolaris/uts/common/fs/zfs vm Message-ID: <20140910192921.GB7129@zxy.spb.ru> References: <201408281950.s7SJo90I047213@svn.freebsd.org> <1540004.aItdQtGhVh@ralph.baldwin.cx> <20140910163058.GA7129@zxy.spb.ru> <1758851.BtHUmxkW3Q@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1758851.BtHUmxkW3Q@ralph.baldwin.cx> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 10 Sep 2014 19:35:30 +0000 Cc: src-committers@freebsd.org, Peter Wemm , Alan Cox , alc@freebsd.org, svn-src-all@freebsd.org, Dmitry Morozovsky , Andriy Gapon , Steven Hartland , "Matthew D. Fuller" , svn-src-head@freebsd.org, Nikolai Lifanov X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 19:29:29 -0000 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.