From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail172.messagelabs.com (mail172.messagelabs.com [216.82.254.3]) by kanga.kvack.org (Postfix) with ESMTP id 3B2CA6B007B for ; Wed, 15 Sep 2010 15:18:37 -0400 (EDT) Received: from wpaz5.hot.corp.google.com (wpaz5.hot.corp.google.com [172.24.198.69]) by smtp-out.google.com with ESMTP id o8FJIXmt006232 for ; Wed, 15 Sep 2010 12:18:33 -0700 Received: from vws18 (vws18.prod.google.com [10.241.21.146]) by wpaz5.hot.corp.google.com with ESMTP id o8FJI7YB026452 for ; Wed, 15 Sep 2010 12:18:32 -0700 Received: by vws18 with SMTP id 18so316170vws.29 for ; Wed, 15 Sep 2010 12:18:29 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <1284571473.21906.428.camel@calx> References: <20100915134724.C9EE.A69D9226@jp.fujitsu.com> <201009151034.22497.knikanth@suse.de> <20100915141710.C9F7.A69D9226@jp.fujitsu.com> <201009151201.11359.knikanth@suse.de> <20100915140911.GC4383@balbir.in.ibm.com> <1284561982.21906.280.camel@calx> <1284571473.21906.428.camel@calx> Date: Wed, 15 Sep 2010 12:18:29 -0700 Message-ID: Subject: Re: [PATCH v2] After swapout/swapin private dirty mappings are reported clean in smaps From: Hugh Dickins Content-Type: text/plain; charset=UTF-8 Sender: owner-linux-mm@kvack.org To: Matt Mackall Cc: Richard Guenther , Balbir Singh , Nikanth Karthikesan , KOSAKI Motohiro , linux-mm@kvack.org, Andrew Morton , Michael Matz , linux-kernel@vger.kernel.org List-ID: On Wed, Sep 15, 2010 at 10:24 AM, Matt Mackall wrote: > But that's my point: the consistency problem is NOT in smaps. The page > is NOT marked dirty, ergo smaps doesn't report it as dirty. Whether or > not there is MORE information smaps could be reporting is irrelevant, > the information it IS reporting is consistent with the underlying VM > data. If there's an inconsistency about what it means to be clean, it's > either in the VM or in your head. > > And I frankly think it's in the VM. I don't believe there's any problem in the VM here, we'd be having SIGSEGVs all over if there were. The problem is that /proc/pid/smaps exports a simplified view of the VM, and Richard and Nikanth were hoping that it gave them some info which it has never pretended to give them, It happens to use a pte_dirty(ptent) test: you could argue that that should be pte_dirty(ptent) || PageDirty(page) (which would then "fix the issue" which Richard sees with swapoff/swapon), or you could argue that it should be pte_dirty(ptent) || PageDirty(page) || PageSwapCache(page) (which would then note clean copies of swap cache as dirty in the sense which Richard and Nikanth are interested in). But after these years, we should probably assume that most users of /proc/pid/smaps are used to the existing pte_dirty(ptent) test, and would be troubled by a departure from it. > > In any case, I don't think Nikanth's fix is the right fix, as it > basically says "you can't trust any of this". Either swap should return > the pages to their pre-swap dirty state in the VM, or we should add > another field here: > > Weird_Anon_Page_You_Should_Pretend_Is_Private_Dirty: 8 kB I think that the most widely useful but simple extension of /proc/pid/smaps, that would give them the info they want, would indeed be to counts ptes pointing to PageAnon pages and report that total on an additional line (say, just before "Swap:"); but there's no need for the derogatory name you propose there, "Anon:" would suit fine! The original idea of testing for vma->anon_vma was a good one, but it doesn't fit so well into the /proc/pid/smaps layout; and showing the actual count of Anon pages could be useful to others (though generally it would be Anon+Swap they'd be interested in). Hugh -- 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