From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f178.google.com (mail-pf0-f178.google.com [209.85.192.178]) by kanga.kvack.org (Postfix) with ESMTP id 13A4C6B0005 for ; Thu, 11 Feb 2016 14:45:07 -0500 (EST) Received: by mail-pf0-f178.google.com with SMTP id q63so34305950pfb.0 for ; Thu, 11 Feb 2016 11:45:07 -0800 (PST) Received: from blackbird.sr71.net (www.sr71.net. [198.145.64.142]) by mx.google.com with ESMTP id e69si14379271pfd.66.2016.02.11.11.45.06 for ; Thu, 11 Feb 2016 11:45:06 -0800 (PST) Subject: Re: [RFC PATCH 3/3] mm: increase scalability of global memory commitment accounting References: <1455115941-8261-1-git-send-email-aryabinin@virtuozzo.com> <1455115941-8261-3-git-send-email-aryabinin@virtuozzo.com> <1455127253.715.36.camel@schen9-desk2.jf.intel.com> <20160210132818.589451dbb5eafae3fdb4a7ec@linux-foundation.org> <1455150256.715.60.camel@schen9-desk2.jf.intel.com> <56BC9281.6090505@virtuozzo.com> <1455214844.715.86.camel@schen9-desk2.jf.intel.com> From: Dave Hansen Message-ID: <56BCE4C0.8070200@sr71.net> Date: Thu, 11 Feb 2016 11:45:04 -0800 MIME-Version: 1.0 In-Reply-To: <1455214844.715.86.camel@schen9-desk2.jf.intel.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Tim Chen , Andrey Ryabinin Cc: Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andi Kleen , Mel Gorman , Vladimir Davydov , Konstantin Khlebnikov On 02/11/2016 10:20 AM, Tim Chen wrote: > The brk1 test is also somewhat pathologic. It > does nothing but brk which is unlikely for real workload. > So we have to be careful when we are tuning our system > behavior for brk1 throughput. We'll need to make sure > whatever changes we made don't impact other more useful > workloads adversely. Yeah, there are *so* many alternatives to using brk() or mmap()/munmap() frequently. glibc has tunables to tune how tightly coupled malloc()/free() are with virtual space allocation. Raising those can reduce the brk() frequency. There are also other allocators that take much larger chunks of virtual address space and then "free" memory with MADV_FREE instead of brk(). I think jemalloc does this, for instance. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751040AbcBKTpI (ORCPT ); Thu, 11 Feb 2016 14:45:08 -0500 Received: from www.sr71.net ([198.145.64.142]:55306 "EHLO blackbird.sr71.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750787AbcBKTpH (ORCPT ); Thu, 11 Feb 2016 14:45:07 -0500 Subject: Re: [RFC PATCH 3/3] mm: increase scalability of global memory commitment accounting To: Tim Chen , Andrey Ryabinin References: <1455115941-8261-1-git-send-email-aryabinin@virtuozzo.com> <1455115941-8261-3-git-send-email-aryabinin@virtuozzo.com> <1455127253.715.36.camel@schen9-desk2.jf.intel.com> <20160210132818.589451dbb5eafae3fdb4a7ec@linux-foundation.org> <1455150256.715.60.camel@schen9-desk2.jf.intel.com> <56BC9281.6090505@virtuozzo.com> <1455214844.715.86.camel@schen9-desk2.jf.intel.com> Cc: Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andi Kleen , Mel Gorman , Vladimir Davydov , Konstantin Khlebnikov From: Dave Hansen Message-ID: <56BCE4C0.8070200@sr71.net> Date: Thu, 11 Feb 2016 11:45:04 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <1455214844.715.86.camel@schen9-desk2.jf.intel.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/11/2016 10:20 AM, Tim Chen wrote: > The brk1 test is also somewhat pathologic. It > does nothing but brk which is unlikely for real workload. > So we have to be careful when we are tuning our system > behavior for brk1 throughput. We'll need to make sure > whatever changes we made don't impact other more useful > workloads adversely. Yeah, there are *so* many alternatives to using brk() or mmap()/munmap() frequently. glibc has tunables to tune how tightly coupled malloc()/free() are with virtual space allocation. Raising those can reduce the brk() frequency. There are also other allocators that take much larger chunks of virtual address space and then "free" memory with MADV_FREE instead of brk(). I think jemalloc does this, for instance.