From patchwork Fri Mar 21 21:17:34 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: John Stultz X-Patchwork-Id: 26883 Return-Path: X-Original-To: linaro@patches.linaro.org Delivered-To: linaro@patches.linaro.org Received: from mail-yk0-f197.google.com (mail-yk0-f197.google.com [209.85.160.197]) by ip-10-151-82-157.ec2.internal (Postfix) with ESMTPS id 6F7B0203AB for ; Fri, 21 Mar 2014 21:18:08 +0000 (UTC) Received: by mail-yk0-f197.google.com with SMTP id 19sf15049827ykq.0 for ; Fri, 21 Mar 2014 14:18:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:delivered-to:from:to:cc:subject :date:message-id:in-reply-to:references:x-original-sender :x-original-authentication-results:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-unsubscribe; bh=zZlb34ECYmL9NwFbygk89UIPIfM0/cR6bO6oB7qJ4oY=; b=FoC8n9iJDyLkcfG18N3/XKyd/tdL5PEFNagCztNMdLTqK5JHswevzQoEFNVUVGB1XQ zXH07ZBtUMSh7kZ2E28TXRtqJqm+k9Q9FkHpdmFQRY/hwd7NwO1nIUBFuLy3+8x+M1WK ZtG7PxU+S5p0LBCP1D5Z8/Fok4aAezZVz5eW10VPo2i4j4yqoRw+EJUziKFx/ZIgubOf lTN6fgnWYCGqfFLwbJOYK4q6j4mu+XXFZPL8R5J13CJRpHNfpzxGuGhiW8jVW97L5ZQQ 6HmOveETj741sBoT/f88ouVDgfHPYxwEtugFYWrxevdmjVFSOHn3XkNQQjRPajfMe1hR 1HiA== X-Gm-Message-State: ALoCoQm5doOk9845p1qvdraNFk3SWIfjarkLdBoKyAy+PeY7DuLfPQ+MAavqs8mPE0xYhV33q6Sm X-Received: by 10.52.2.129 with SMTP id 1mr8285217vdu.4.1395436688201; Fri, 21 Mar 2014 14:18:08 -0700 (PDT) MIME-Version: 1.0 X-BeenThere: patchwork-forward@linaro.org Received: by 10.140.81.8 with SMTP id e8ls854321qgd.39.gmail; Fri, 21 Mar 2014 14:18:08 -0700 (PDT) X-Received: by 10.52.165.105 with SMTP id yx9mr32967690vdb.22.1395436688092; Fri, 21 Mar 2014 14:18:08 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by mx.google.com with ESMTPS id rx10si1456976vdc.24.2014.03.21.14.18.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Mar 2014 14:18:08 -0700 (PDT) Received-SPF: neutral (google.com: 209.85.220.172 is neither permitted nor denied by best guess record for domain of patch+caf_=patchwork-forward=linaro.org@linaro.org) client-ip=209.85.220.172; Received: by mail-vc0-f172.google.com with SMTP id la4so3264265vcb.31 for ; Fri, 21 Mar 2014 14:18:08 -0700 (PDT) X-Received: by 10.52.78.231 with SMTP id e7mr18934041vdx.28.1395436687952; Fri, 21 Mar 2014 14:18:07 -0700 (PDT) X-Forwarded-To: patchwork-forward@linaro.org X-Forwarded-For: patch@linaro.org patchwork-forward@linaro.org Delivered-To: patches@linaro.org Received: by 10.220.78.9 with SMTP id i9csp59702vck; Fri, 21 Mar 2014 14:18:07 -0700 (PDT) X-Received: by 10.66.227.104 with SMTP id rz8mr56389362pac.74.1395436680037; Fri, 21 Mar 2014 14:18:00 -0700 (PDT) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx.google.com with ESMTPS id hw8si4394615pbc.77.2014.03.21.14.17.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Mar 2014 14:18:00 -0700 (PDT) Received-SPF: neutral (google.com: 209.85.220.54 is neither permitted nor denied by best guess record for domain of john.stultz@linaro.org) client-ip=209.85.220.54; Received: by mail-pa0-f54.google.com with SMTP id lf10so2919246pab.13 for ; Fri, 21 Mar 2014 14:17:59 -0700 (PDT) X-Received: by 10.68.58.34 with SMTP id n2mr57095357pbq.122.1395436679555; Fri, 21 Mar 2014 14:17:59 -0700 (PDT) Received: from localhost.localdomain (c-67-170-153-23.hsd1.or.comcast.net. [67.170.153.23]) by mx.google.com with ESMTPSA id os1sm31409893pac.20.2014.03.21.14.17.58 for (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Mar 2014 14:17:58 -0700 (PDT) From: John Stultz To: LKML Cc: John Stultz , Andrew Morton , Android Kernel Team , Johannes Weiner , Robert Love , Mel Gorman , Hugh Dickins , Dave Hansen , Rik van Riel , Dmitry Adamushko , Neil Brown , Andrea Arcangeli , Mike Hommey , Taras Glek , Jan Kara , KOSAKI Motohiro , Michel Lespinasse , Minchan Kim , "linux-mm@kvack.org" Subject: [PATCH 4/5] vrange: Set affected pages referenced when marking volatile Date: Fri, 21 Mar 2014 14:17:34 -0700 Message-Id: <1395436655-21670-5-git-send-email-john.stultz@linaro.org> X-Mailer: git-send-email 1.8.3.2 In-Reply-To: <1395436655-21670-1-git-send-email-john.stultz@linaro.org> References: <1395436655-21670-1-git-send-email-john.stultz@linaro.org> X-Removed-Original-Auth: Dkim didn't pass. X-Original-Sender: john.stultz@linaro.org X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 209.85.220.172 is neither permitted nor denied by best guess record for domain of patch+caf_=patchwork-forward=linaro.org@linaro.org) smtp.mail=patch+caf_=patchwork-forward=linaro.org@linaro.org Precedence: list Mailing-list: list patchwork-forward@linaro.org; contact patchwork-forward+owners@linaro.org List-ID: X-Google-Group-Id: 836684582541 List-Post: , List-Help: , List-Archive: List-Unsubscribe: , One issue that some potential users were concerned about, was that they wanted to ensure that all the pages from one volatile range were purged before we purge pages from a different volatile range. This would prevent the case where they have 4 large objects, and the system purges one page from each object, casuing all of the objects to have to be re-created. The counter-point to this case, is when an application is using the SIGBUS semantics to continue to access pages after they have been marked volatile. In that case, the desire was that the most recently touched pages be purged last, and only the "cold" pages be purged from the specified range. Instead of adding option flags for the various usage model (at least initially), one way of getting a solutoin for both uses would be to have the act of marking pages as volatile in effect mark the pages as accessed. Since all of the pages in the range would be marked together, they would be of the same "age" and would (approximately) be purged together. Further, if any pages in the range were accessed after being marked volatile, they would be moved to the end of the lru and be purged later. This patch provides this solution by walking the pages in the range and setting them accessed when set volatile. This does have a performance impact, as we have to touch each page when setting them volatile. Additionally, while setting all the pages to the same age solves the basic problem, there is still an open question of: What age all the pages should be set to? One could consider them all recently accessed, which would put them at the end of the active lru. Or one could possibly move them all to the end of the inactive lru, making them more likely to be purged sooner. Another possibility would be to not affect the pages at all when marking them as volatile, and allow applications to use madvise prior to marking any pages as volatile to age them together, if that behavior was needed. In that case this patch would be unnecessary. Thoughts on the best approach would be greatly appreciated. Cc: Andrew Morton Cc: Android Kernel Team Cc: Johannes Weiner Cc: Robert Love Cc: Mel Gorman Cc: Hugh Dickins Cc: Dave Hansen Cc: Rik van Riel Cc: Dmitry Adamushko Cc: Neil Brown Cc: Andrea Arcangeli Cc: Mike Hommey Cc: Taras Glek Cc: Jan Kara Cc: KOSAKI Motohiro Cc: Michel Lespinasse Cc: Minchan Kim Cc: linux-mm@kvack.org Signed-off-by: John Stultz --- mm/vrange.c | 71 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 71 insertions(+) diff --git a/mm/vrange.c b/mm/vrange.c index 28ceb6f..9be8f45 100644 --- a/mm/vrange.c +++ b/mm/vrange.c @@ -79,6 +79,73 @@ static int vrange_check_purged(struct mm_struct *mm, } + +/** + * vrange_mark_accessed_pte - Marks pte pages in range accessed + * + * Iterates over the ptes in the pmd and marks the coresponding page + * as accessed. This ensures all the pages in the range are of the + * same "age", so that when pages are purged, we will most likely purge + * them together. + */ +static int vrange_mark_accessed_pte(pmd_t *pmd, unsigned long addr, + unsigned long end, struct mm_walk *walk) +{ + struct vm_area_struct *vma = walk->private; + pte_t *pte; + spinlock_t *ptl; + + if (pmd_trans_huge(*pmd)) + return 0; + if (pmd_trans_unstable(pmd)) + return 0; + + pte = pte_offset_map_lock(walk->mm, pmd, addr, &ptl); + for (; addr != end; pte++, addr += PAGE_SIZE) { + if (pte_present(*pte)) { + struct page *page; + + page = vm_normal_page(vma, addr, *pte); + if (IS_ERR_OR_NULL(page)) + break; + get_page(page); + /* + * XXX - So here we may want to do something + * else other then marking the page accessed. + * Setting them to all be the same "age" ensures + * they are pruged together, but its not clear + * what that "age" should be. + */ + mark_page_accessed(page); + put_page(page); + } + } + pte_unmap_unlock(pte - 1, ptl); + cond_resched(); + + return 0; +} + + +/** + * vrange_mark_range_accessed - Sets up a mm_walk to mark pages accessed + * + * Sets up and calls wa_page_range() to mark affected pages as accessed. + */ +static void vrange_mark_range_accessed(struct vm_area_struct *vma, + unsigned long start, + unsigned long end) +{ + struct mm_walk vrange_walk = { + .pmd_entry = vrange_mark_accessed_pte, + .mm = vma->vm_mm, + .private = vma, + }; + + walk_page_range(start, end, &vrange_walk); +} + + /** * do_vrange - Marks or clears VMAs in the range (start-end) as VM_VOLATILE * @@ -165,6 +232,10 @@ static ssize_t do_vrange(struct mm_struct *mm, unsigned long start, success: vma->vm_flags = new_flags; + /* Mark the vma range as accessed */ + if (mode == VRANGE_VOLATILE) + vrange_mark_range_accessed(vma, start, tmp); + /* update count to distance covered so far*/ count = tmp - orig_start;