From: KOSAKI Motohiro <kosaki.motohiro@gmail.com>
To: Pavel Emelyanov <xemul@parallels.com>
Cc: Linux MM <linux-mm@kvack.org>,
Andrew Morton <akpm@linux-foundation.org>,
Matt Mackall <mpm@selenic.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Glauber Costa <glommer@parallels.com>,
Matthew Wilcox <willy@linux.intel.com>,
kosaki.motohiro@gmail.com
Subject: Re: [RFC PATCH 1/1] mm: Another attempt to monitor task's memory changes
Date: Mon, 08 Apr 2013 19:10:16 -0400 [thread overview]
Message-ID: <51634E58.4080104@gmail.com> (raw)
In-Reply-To: <515F0484.1010703@parallels.com>
> This approach works on any task via it's proc, and can be used on different
> tasks in parallel.
>
> Also, Andrew was asking for some performance numbers related to the change.
> Now I can say, that as long as soft dirty bits are not cleared, no performance
> penalty occur, since the soft dirty bit and the regular dirty bit are set at
> the same time within the same instruction. When soft dirty is cleared via
> clear_refs, the task in question might slow down, but it will depend on how
> actively it uses the memory.
>
>
> What do you think, does it make sense to develop this approach further?
When touching mmaped page, cpu turns on dirty bit but doesn't turn on soft dirty.
So, I'm not convinced how to use this flag. Please show us your userland algorithm
how to detect diff.
--
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>
next prev parent reply other threads:[~2013-04-08 23:10 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-05 17:06 [RFC PATCH 1/1] mm: Another attempt to monitor task's memory changes Pavel Emelyanov
2013-04-08 22:30 ` Andrew Morton
2013-04-09 15:08 ` Pavel Emelyanov
2013-04-08 23:10 ` KOSAKI Motohiro [this message]
2013-04-09 14:52 ` Pavel Emelyanov
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=51634E58.4080104@gmail.com \
--to=kosaki.motohiro@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=glommer@parallels.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mpm@selenic.com \
--cc=willy@linux.intel.com \
--cc=xemul@parallels.com \
/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).