Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752497Ab2KCH6T (ORCPT ); Sat, 3 Nov 2012 03:58:19 -0400 Received: from mail-ea0-f174.google.com ([209.85.215.174]:43103 "EHLO mail-ea0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751393Ab2KCH6R (ORCPT ); Sat, 3 Nov 2012 03:58:17 -0400 MIME-Version: 1.0 In-Reply-To: <506B6CE0.1060800@linaro.org> References: <1348888593-23047-1-git-send-email-john.stultz@linaro.org> <20121002173928.2062004e@notabene.brown> <506B6CE0.1060800@linaro.org> From: Michael Kerrisk Date: Sat, 3 Nov 2012 08:57:55 +0100 X-Google-Sender-Auth: i1zSjRdlgM2Rv5r1XjIcJUcp71s Message-ID: Subject: Re: [PATCH 0/3] Volatile Ranges (v7) & Lots of words To: John Stultz Cc: NeilBrown , LKML , Andrew Morton , Android Kernel Team , Robert Love , Mel Gorman , Hugh Dickins , Dave Hansen , Rik van Riel , Dmitry Adamushko , Dave Chinner , Andrea Righi , "Aneesh Kumar K.V" , Mike Hommey , Taras Glek , Jan Kara , KOSAKI Motohiro , Michel Lespinasse , Minchan Kim , "linux-mm@kvack.org" , Christoph Hellwig , Linux API , Jake Edge , Michael Kerrisk 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: 3007 Lines: 73 [CC += linux-api, since this is an API change.] Hi John, A couple of other questions that occurred to me... What are the expected/planned semantics of volatile ranges for mlocked pages? I noticed that Minchan's patch series (https://lwn.net/Articles/522154/) gives an error on attempt to mark locked pages as volatile (which seems sensible). I didn't see anything similar in your patches. Perhaps it's not easy to do because of the non-VMA-based implementation? Something to think about. On Wed, Oct 3, 2012 at 12:38 AM, John Stultz wrote: > On 10/02/2012 12:39 AM, NeilBrown wrote: >> >> On Fri, 28 Sep 2012 23:16:30 -0400 John Stultz >> wrote: >> >> For example, allowing sub-page volatile region seems to be above and >> beyond >> the call of duty. You cannot mmap sub-pages, so why should they be >> volatile? > > Although if someone marked a page and a half as volatile, would it be > reasonable to throw away the second half of that second page? That seems > unexpected to me. So we're really only marking the whole pages specified as > volatlie, similar to how FALLOC_FL_PUNCH_HOLE behaves. > > But if it happens that the adjacent range is also a partial page, we can > coalesce them possibly into an purgable whole page. I think it makes sense, > especially from a userland point of view and wasn't really complicated to > add. I must confess that I'm puzzled by this facility to lock sub-page range ranges as well. What's the use case? What I'm thinking is: the goal of volatile ranges is to help improve system performance by freeing up a (sizeable) block of pages. Why then would the user care too much about marking with sub-page granularity, or that such ranges might be merged? After all, the system calls to do this marking are expensive, and so for performance reasons, I suppose that a process would like to keep those system calls to a minimum. [...] >> I think discarding whole ranges at a time is very sensible, and so >> merging >> adjacent ranges is best avoided. If you require page-aligned ranges >> this >> becomes trivial - is that right? > > True. If we avoid coalescing non-whole page ranges, keeping non-overlapping > ranges independent is fairly easy. Regarding coalescing of adjacent ranges. Here's one possible argument against it (Jake Edge alerted me to this). If an application marked adjacent ranges using separate system calls, that might be an indication that the application intends to to have different access patterns against the two ranges: one frequent, the other rare. In that case, I suppose it would be better if the ranges were not merged. Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ -- 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/