Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759527Ab3FNAVb (ORCPT ); Thu, 13 Jun 2013 20:21:31 -0400 Received: from LGEMRELSE7Q.lge.com ([156.147.1.151]:60665 "EHLO LGEMRELSE7Q.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754609Ab3FNAVa (ORCPT ); Thu, 13 Jun 2013 20:21:30 -0400 X-AuditID: 9c930197-b7b8cae000003b08-59-51ba6207a01b Date: Fri, 14 Jun 2013 09:21:32 +0900 From: Minchan Kim To: John Stultz Cc: LKML , Andrew Morton , Android Kernel Team , Robert Love , Mel Gorman , Hugh Dickins , Dave Hansen , Rik van Riel , Dmitry Adamushko , Dave Chinner , Neil Brown , Andrea Righi , Andrea Arcangeli , "Aneesh Kumar K.V" , Mike Hommey , Taras Glek , Dhaval Giani , Jan Kara , KOSAKI Motohiro , Michel Lespinasse , "linux-mm@kvack.org" Subject: Re: [PATCH 4/8] vrange: Clear volatility on new mmaps Message-ID: <20130614002132.GC4533@bbox> References: <1371010971-15647-1-git-send-email-john.stultz@linaro.org> <1371010971-15647-5-git-send-email-john.stultz@linaro.org> <20130613062815.GB5209@bbox> <51BA593E.9000102@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51BA593E.9000102@linaro.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Brightmail-Tracker: AAAAAA== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5056 Lines: 167 Hello John, On Thu, Jun 13, 2013 at 04:43:58PM -0700, John Stultz wrote: > On 06/12/2013 11:28 PM, Minchan Kim wrote: > >Hey John, > > > >On Tue, Jun 11, 2013 at 09:22:47PM -0700, John Stultz wrote: > >>At lsf-mm, the issue was brought up that there is a precedence with > >>interfaces like mlock, such that new mappings in a pre-existing range > >>do no inherit the mlock state. > >> > >>This is mostly because mlock only modifies the existing vmas, and so > >>any new mmaps create new vmas, which won't be mlocked. > >> > >>Since volatility is not stored in the vma (for good cause, specfically > >>as we'd have to have manage file volatility differently from anonymous > >>and we're likely to manage volatility on small chunks of memory, which > >>would cause lots of vma splitting and churn), this patch clears volatilty > >>on new mappings, to ensure that we don't inherit volatility if memory in > >>an existing volatile range is unmapped and then re-mapped with something > >>else. > >> > >>Thus, this patch forces any volatility to be cleared on mmap. > >If we have lots of node on vroot but it doesn't include newly mmmaping > >vma range, it's purely unnecessary cost and that's never what we want. > > > >>XXX: We expect this patch to be not well loved by mm folks, and are open > >>to alternative methods here. Its more of a place holder to address > >>the issue from lsf-mm and hopefully will spur some further discussion. > >Another idea is we can add "bool is_vrange" in struct vm_area_struct. > >It is protected by vrange_lock. The scenario is following as, > > > >When do_vrange is called with VRANGE_VOLATILE, it iterates vmas > >and mark the vma->is_vrange to true. So, we can avoid tree traversal > >if the is_vrange is false when munmap is called and newly mmaped vma > >doesn't need to clear any volatility. > > We could look further into this approach if folks think its the best > way to go. Though it has the downside of having the split the vmas > when we're dealing with a large number of smallish objects. Also We don't need to split vma, which I don't really want. I meant followig as 1) 0x100000 0x10000000 | VMA : isvrange = false | 2) vrange(0x200000, 0x100000, VRANGE_VOLATILE) 0x100000 0x10000000 | VMA : isvrange = true | vroot / node 1 2) vrange(0x400000, 0x100000, VRANGE_VOLATILE) 0x100000 0x10000000 | VMA : isvrange = true | vroot / \ node 1 node 2 3) unmap(0x400000, 0x100000, VRANGE_NOVOLATILE) sys_munmap: if (vma->is_vrange) { vrange_clear(0x400000, 0x400000 + 0x100000 -1); if (vma_vrange_all_clear(vma) vma->isvrange = false; } 0x100000 0x10000000 | VMA : isvrange = true | vroot / node 1 3) unmap(0x200000, 0x100000, VRANGE_NOVOLATILE) sys_munmap: if (vma->is_vrange) { vrange_clear(0x200000, 0x200000 + 0x100000 -1); if (vma_vrange_all_clear(vma) vma->isvrange = false; } 0x100000 0x10000000 | VMA : isvrange = false | vroot / \ 4) purging path bool really_vrange_page(page *page) { return __vrange_address(vroot, startofpage, endofpage); } shrink_page_list .. .. vma = rmap_from_page(page); if (vma->is_vrange) { /* * vma's is_vrange could have false positive * so that we should check it. */ if (really_vrange_page(page)) purge_page(page); } .. .. So we can reduce unnecessary vroot traverse without vma splitting. > we'd be increasing the vma_struct size for everyone, even if no one > is using volatile ranges, which may be a bigger concern. I think vma is not a sensitive about size and historically, we have been added a variable easily. Of course, another ideas which don't need to increase vma size are welcome but IMHO, it'a good compromise between performance and memoryfootprint. > > Also it means we'd be managing anonymous and file volatility with > different structures (though that's not the end of the world). volatility still is kept in vrange->purged. Do I miss something? > > thanks > -john > > -- > 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 -- Kind regards, Minchan Kim -- 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/