Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761089Ab2JaW42 (ORCPT ); Wed, 31 Oct 2012 18:56:28 -0400 Received: from mail-oa0-f46.google.com ([209.85.219.46]:54823 "EHLO mail-oa0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754606Ab2JaW40 (ORCPT ); Wed, 31 Oct 2012 18:56:26 -0400 MIME-Version: 1.0 In-Reply-To: References: <1351560594-18366-1-git-send-email-minchan@kernel.org> <20121031143524.0509665d.akpm@linux-foundation.org> From: KOSAKI Motohiro Date: Wed, 31 Oct 2012 18:56:05 -0400 Message-ID: Subject: Re: [RFC v2] Support volatile range for anon vma To: Paul Turner Cc: Andrew Morton , Minchan Kim , linux-kernel@vger.kernel.org, linux-mm@kvack.org, John Stultz , Christoph Lameter , Android Kernel Team , Robert Love , Mel Gorman , Hugh Dickins , Dave Hansen , Rik van Riel , Dave Chinner , Neil Brown , Mike Hommey , Taras Glek , KAMEZAWA Hiroyuki , sanjay@google.com, David Rientjes Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1951 Lines: 42 >> > Allocator should call madvise(MADV_NOVOLATILE) before reusing for >> > allocating that area to user. Otherwise, accessing of volatile range >> > will meet SIGBUS error. >> >> Well, why? It would be easy enough for the fault handler to give >> userspace a new, zeroed page at that address. > > Note: MADV_DONTNEED already has this (nice) property. I don't think I strictly understand this patch. but maybe I can answer why userland and malloc folks don't like MADV_DONTNEED. glibc malloc discard freed memory by using MADV_DONTNEED as tcmalloc. and it is often a source of large performance decrease. because of MADV_DONTNEED discard memory immediately and right after malloc() call fall into page fault and pagesize memset() path. then, using DONTNEED increased zero fill and cache miss rate. At called free() time, malloc don't have a knowledge when next big malloc() is called. then, immediate discarding may or may not get good performance gain. (Ah, ok, the rate is not 5:5. then usually it is worth. but not everytime) In past, several developers tryied to avoid such situation, likes - making zero page daemon and avoid pagesize zero fill at page fault - making new vma or page flags and mark as discardable w/o swap and vmscan treat it. (like this and/or MADV_FREE) - making new process option and avoid page zero fill from page fault path. (yes, it is big incompatibility and insecure. but some embedded folks thought they are acceptable downside) - etc btw, I'm not sure this patch is better for malloc because current MADV_DONTNEED don't need mmap_sem and works very effectively when a lot of threads case. taking mmap_sem might bring worse performance than DONTNEED. dunno. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/