Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935308Ab3DKIbv (ORCPT ); Thu, 11 Apr 2013 04:31:51 -0400 Received: from LGEMRELSE1Q.lge.com ([156.147.1.111]:44854 "EHLO LGEMRELSE1Q.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752932Ab3DKIbs (ORCPT ); Thu, 11 Apr 2013 04:31:48 -0400 X-AuditID: 9c93016f-b7b3fae0000004d3-fe-516674f2dedd Date: Thu, 11 Apr 2013 17:31:46 +0900 From: Minchan Kim To: KOSAKI Motohiro Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Michael Kerrisk , Arun Sharma , John Stultz , Mel Gorman , Hugh Dickins , Dave Hansen , Rik van Riel , Neil Brown , Mike Hommey , Taras Glek , KOSAKI Motohiro , KAMEZAWA Hiroyuki , Jason Evans , sanjay@google.com, Paul Turner , Johannes Weiner , Michel Lespinasse , Andrew Morton Subject: Re: [RFC v7 00/11] Support vrange for anonymous page Message-ID: <20130411083146.GB12626@blaptop> References: <1363073915-25000-1-git-send-email-minchan@kernel.org> <5165CA22.6080808@gmail.com> <20130411065546.GA10303@blaptop> <5166643E.6050704@gmail.com> <20130411080243.GA12626@blaptop> <5166712C.7040802@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5166712C.7040802@gmail.com> 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: 5146 Lines: 123 On Thu, Apr 11, 2013 at 04:15:40AM -0400, KOSAKI Motohiro wrote: > (4/11/13 4:02 AM), Minchan Kim wrote: > > On Thu, Apr 11, 2013 at 03:20:30AM -0400, KOSAKI Motohiro wrote: > >>>>> DONTNEED makes sure user always can see zero-fill pages after > >>>>> he calls madvise while vrange can see data or encounter SIGBUS. > >>>> > >>>> For replacing DONTNEED, user want to zero-fill pages like DONTNEED > >>>> instead of SIGBUS. So, new flag option would be nice. > >>> > >>> If userspace people want it, I can do it. > >>> But not sure they want it at the moment becaue vrange is rather > >>> different concept of madvise(DONTNEED) POV usage. > >>> > >>> As you know well, in case of DONTNEED, user calls madvise _once_ and > >>> VM releases memory as soon as he called system call. > >>> But vrange is same with delayed free when the system memory pressure > >>> happens so user can't know OS frees the pages anytime. > >>> It means user should call pair of system call both VRANGE_VOLATILE > >>> and VRANGE_NOVOLATILE for right usage of volatile range > >>> (for simple, I don't want to tell SIGBUS fault recovery method). > >>> If he took a mistake(ie, NOT to call VRANGE_NOVOLATILE) on the range > >>> which is used by current process, pages used by some process could be > >>> disappeared suddenly. > >>> > >>> In summary, I don't think vrange is a replacement of madvise(DONTNEED) > >>> but could be useful with madvise(DONTNEED) friend. For example, we can > >>> make return 1 in vrange(VRANGE_VOLATILE) if memory pressure was already > >> > >> Do you mean vrange(VRANGE_UNVOLATILE)? > > > > I meant VRANGE_VOLATILE. It seems my explanation was poor. Here it goes, again. > > Now vrange's semantic return just 0 if the system call is successful, otherwise, > > return error. But we can change it as folows > > > > 1. return 0 if the system call is successful and memory pressure isn't severe > > 2. return 1 if the system call is successful and memory pressure is severe > > 3. return -ERRXXX if the system call is failed by some reason > > > > So the process can know system-wide memory pressure without peeking the vmstat > > and then call madvise(DONTNEED) right after vrange call. The benefit is system > > can zap all pages instantly. > > Do you mean your patchset is not latest? and when do you use this feature? what's Yes. I meant I can it in next spin up for hearing the opinion. > happen VRANGE_VOLATILE return 0 and purge the range just after returning syscall. It could be an idea but I will think it over. > > > >> btw, assign new error number to asm-generic/errno.h is better than strange '1'. > > > > I can and admit "1" is rather weired. > > But it's not error, either. > > If this is really necessary, I don't oppose it. However I am still not convinced. > > > > >>> severe so user can catch up memory pressure by return value and calls > >>> madvise(DONTNEED) if memory pressure was already severe. Of course, we > >>> can handle it vrange system call itself(ex, change vrange system call to > >>> madvise(DONTNEED) but don't want it because I want to keep vrange hinting > >>> sytem call very light at all times so user can expect latency. > >> > >> For allocator usage, vrange(UNVOLATILE) is annoying and don't need at all. > >> When data has already been purged, just return new zero filled page. so, > >> maybe adding new flag is worthwhile. Because malloc is definitely fast path > > > > I really want it and it's exactly same with madvise(MADV_FREE). > > But for implementation, we need page granularity someting in address range > > in system call context like zap_pte_range(ex, clear page table bits and > > mark something to page flags for reclaimer to detect it). > > It means vrange system call is still bigger although we are able to remove > > lazy page fault. > > > > Do you have any idea to remove it? If so, I'm very open to implement it. > > Hm. Maybe I am missing something. I'll look the code closely after LFS. Please see the Rik's old work about MADV_FREE. > > > >> and adding new syscall invokation is unwelcome. > > > > Sure. But one more system call could be cheaper than page-granuarity > > operation on purged range. > > I don't think vrange(VOLATILE) cost is the related of this discusstion. > Whether sending SIGBUS or just nuke pte, purge should be done on vmscan, > not vrange() syscall. Again, please see the MADV_FREE. http://lwn.net/Articles/230799/ It does changes pte and page flags on all pages of the range through zap_pte_range. So it would make vrange(VOLASTILE) expensive and the bigger cost is, the bigger range is. > > > > > > > > > > -- > 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/