linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Matt Mackall <mpm@selenic.com>
To: Hugh Dickins <hugh.dickins@tiscali.co.uk>
Cc: Richard Guenther <rguenther@suse.de>,
	Balbir Singh <balbir@linux.vnet.ibm.com>,
	Nikanth Karthikesan <knikanth@suse.de>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
	Michael Matz <matz@novell.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] After swapout/swapin private dirty mappings are reported clean in smaps
Date: Wed, 15 Sep 2010 14:46:09 -0500	[thread overview]
Message-ID: <1284579969.21906.451.camel@calx> (raw)
In-Reply-To: <AANLkTimYQgm6nKZ4TantPiL4kmUP9FtMQwzqeetVnGrr@mail.gmail.com>

On Wed, 2010-09-15 at 12:18 -0700, Hugh Dickins wrote:
> On Wed, Sep 15, 2010 at 10:24 AM, Matt Mackall <mpm@selenic.com> 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.

Of course it works. It's just not as orthogonal (aka consistent) as it
could be in this case: it's not actually reflecting any of the usual
meanings of dirtiness here.

> 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),

That might be interesting. Are there any other notable cases where
pte_dirty() differs from PageDirty()?

>  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.

Dunno, my smem tool[1] is probably also expecting too much here and I
should know better!

> > 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!

Yes, that wasn't a serious suggestion.

[1] http://www.selenic.com/smem/
-- 
Mathematics is the supreme nostalgia of our time.


--
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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2010-09-15 19:46 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-14 11:10 [PATCH] After swapout/swapin private dirty mappings become clean Nikanth Karthikesan
2010-09-14 11:33 ` Richard Guenther
2010-09-14 17:12   ` Nikanth Karthikesan
2010-09-14 17:14     ` [PATCH v2] After swapout/swapin private dirty mappings are reported clean in smaps Nikanth Karthikesan
2010-09-15  0:26       ` KOSAKI Motohiro
2010-09-15  4:38         ` Nikanth Karthikesan
2010-09-15  4:48           ` KOSAKI Motohiro
2010-09-15  5:04             ` Nikanth Karthikesan
2010-09-15  5:20               ` KOSAKI Motohiro
2010-09-15  6:31                 ` Nikanth Karthikesan
2010-09-15 14:09                   ` Balbir Singh
2010-09-15 14:14                     ` Richard Guenther
2010-09-15 14:46                       ` Matt Mackall
2010-09-15 14:53                         ` Richard Guenther
2010-09-15 17:24                           ` Matt Mackall
2010-09-15 19:08                             ` Richard Guenther
2010-09-15 19:18                             ` Hugh Dickins
2010-09-15 19:46                               ` Matt Mackall [this message]
2010-09-15 19:53                                 ` Richard Guenther
2010-09-15 21:47                                 ` Hugh Dickins
2010-09-16  3:26                                   ` [PATCH] Export amount of anonymous memory in a mapping via smaps Nikanth Karthikesan
2010-09-16  3:52                                     ` KOSAKI Motohiro
2010-09-16  6:04                                       ` [PATCH] Document the new Anonymous field in smaps Nikanth Karthikesan
2010-09-16  6:34                                         ` [PATCH] smaps: fix dirty pages accounting KOSAKI Motohiro
2010-09-16 16:56                                           ` Hugh Dickins
2010-09-16 16:50                                         ` [PATCH] Document the new Anonymous field in smaps Hugh Dickins
2010-09-17  6:04                                           ` [PATCH v2] " Nikanth Karthikesan
2010-09-20  7:11                                             ` Hugh Dickins
2010-09-20 19:24                                               ` Matt Mackall
2010-09-16 16:40                                     ` [PATCH] Export amount of anonymous memory in a mapping via smaps Hugh Dickins
2010-09-15 17:41                       ` [PATCH v2] After swapout/swapin private dirty mappings are reported clean in smaps Balbir Singh
2010-09-19 17:37                       ` Nikanth Karthikesan
2010-09-19 17:38                         ` [PATCH] Document /proc/pid/pagemap in Documentation/filesystems/proc.txt Nikanth Karthikesan
2010-09-20 21:27                           ` Matt Mackall
2010-09-20  5:24                         ` [PATCH v2] After swapout/swapin private dirty mappings are reported clean in smaps Nikanth Karthikesan
2010-09-20 14:30                         ` Richard Guenther
2010-09-15  0:24 ` [PATCH] After swapout/swapin private dirty mappings become clean KOSAKI Motohiro
2010-09-15  4:37   ` Nikanth Karthikesan
2010-09-15  4:46     ` KOSAKI Motohiro
2010-09-15  5:00       ` Nikanth Karthikesan
2010-09-15  5:15         ` KOSAKI Motohiro
2010-09-15  6:29           ` Nikanth Karthikesan
2010-09-15  8:40         ` Richard Guenther
2010-09-16  1:29           ` KOSAKI Motohiro

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1284579969.21906.451.camel@calx \
    --to=mpm@selenic.com \
    --cc=akpm@linux-foundation.org \
    --cc=balbir@linux.vnet.ibm.com \
    --cc=hugh.dickins@tiscali.co.uk \
    --cc=knikanth@suse.de \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=matz@novell.com \
    --cc=rguenther@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).