From: Andrew Morton <akpm@linux-foundation.org> To: Michal Hocko <mhocko@kernel.org> Cc: Johannes Weiner <hannes@cmpxchg.org>, Shaohua Li <shli@fb.com>, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Kernel-team@fb.com, minchan@kernel.org, hughd@google.com, riel@redhat.com, mgorman@techsingularity.net Subject: Re: [PATCH V5 6/6] proc: show MADV_FREE pages info in smaps Date: Tue, 7 Mar 2017 14:43:38 -0800 [thread overview] Message-ID: <20170307144338.023080a8cd600172f37dfe16@linux-foundation.org> (raw) In-Reply-To: <20170307100545.GC28642@dhcp22.suse.cz> On Tue, 7 Mar 2017 11:05:45 +0100 Michal Hocko <mhocko@kernel.org> wrote: > On Fri 03-03-17 16:10:27, Andrew Morton wrote: > > On Thu, 2 Mar 2017 17:30:54 +0100 Michal Hocko <mhocko@kernel.org> wrote: > > > > > > It's not that I think you're wrong: it *is* an implementation detail. > > > > But we take a bit of incoherency from batching all over the place, so > > > > it's a little odd to take a stand over this particular instance of it > > > > - whether demanding that it'd be fixed, or be documented, which would > > > > only suggest to users that this is special when it really isn't etc. > > > > > > I am not aware of other counter printed in smaps that would suffer from > > > the same problem, but I haven't checked too deeply so I might be wrong. > > > > > > Anyway it seems that I am alone in my position so I will not insist. > > > If we have any bug report then we can still fix it. > > > > A single lru_add_drain_all() right at the top level (in smaps_show()?) > > won't kill us > > I do not think we want to put lru_add_drain_all cost to a random > process reading /proc/<pid>/smaps. Why not? It's that process which is calling for the work to be done. > If anything the one which does the > madvise should be doing this. But it would be silly to do extra work in madvise() if nobody will be reading smaps for the next two months. How much work is it anyway? What would be the relative impact upon a smaps read?
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org> To: Michal Hocko <mhocko@kernel.org> Cc: Johannes Weiner <hannes@cmpxchg.org>, Shaohua Li <shli@fb.com>, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Kernel-team@fb.com, minchan@kernel.org, hughd@google.com, riel@redhat.com, mgorman@techsingularity.net Subject: Re: [PATCH V5 6/6] proc: show MADV_FREE pages info in smaps Date: Tue, 7 Mar 2017 14:43:38 -0800 [thread overview] Message-ID: <20170307144338.023080a8cd600172f37dfe16@linux-foundation.org> (raw) In-Reply-To: <20170307100545.GC28642@dhcp22.suse.cz> On Tue, 7 Mar 2017 11:05:45 +0100 Michal Hocko <mhocko@kernel.org> wrote: > On Fri 03-03-17 16:10:27, Andrew Morton wrote: > > On Thu, 2 Mar 2017 17:30:54 +0100 Michal Hocko <mhocko@kernel.org> wrote: > > > > > > It's not that I think you're wrong: it *is* an implementation detail. > > > > But we take a bit of incoherency from batching all over the place, so > > > > it's a little odd to take a stand over this particular instance of it > > > > - whether demanding that it'd be fixed, or be documented, which would > > > > only suggest to users that this is special when it really isn't etc. > > > > > > I am not aware of other counter printed in smaps that would suffer from > > > the same problem, but I haven't checked too deeply so I might be wrong. > > > > > > Anyway it seems that I am alone in my position so I will not insist. > > > If we have any bug report then we can still fix it. > > > > A single lru_add_drain_all() right at the top level (in smaps_show()?) > > won't kill us > > I do not think we want to put lru_add_drain_all cost to a random > process reading /proc/<pid>/smaps. Why not? It's that process which is calling for the work to be done. > If anything the one which does the > madvise should be doing this. But it would be silly to do extra work in madvise() if nobody will be reading smaps for the next two months. How much work is it anyway? What would be the relative impact upon a smaps read? -- 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:[~2017-03-08 1:22 UTC|newest] Thread overview: 88+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-02-24 21:31 [PATCH V5 0/6] mm: fix some MADV_FREE issues Shaohua Li 2017-02-24 21:31 ` Shaohua Li 2017-02-24 21:31 ` [PATCH V5 1/6] mm: delete unnecessary TTU_* flags Shaohua Li 2017-02-24 21:31 ` Shaohua Li 2017-02-27 13:48 ` Michal Hocko 2017-02-27 13:48 ` Michal Hocko 2017-02-24 21:31 ` [PATCH V5 2/6] mm: don't assume anonymous pages have SwapBacked flag Shaohua Li 2017-02-24 21:31 ` Shaohua Li 2017-02-27 6:48 ` Hillf Danton 2017-02-27 6:48 ` Hillf Danton 2017-02-27 14:35 ` Michal Hocko 2017-02-27 14:35 ` Michal Hocko 2017-02-27 16:10 ` Shaohua Li 2017-02-27 16:10 ` Shaohua Li 2017-02-27 16:28 ` Michal Hocko 2017-02-27 16:28 ` Michal Hocko 2017-02-24 21:31 ` [PATCH V5 3/6] mm: move MADV_FREE pages into LRU_INACTIVE_FILE list Shaohua Li 2017-02-24 21:31 ` Shaohua Li 2017-02-27 6:28 ` Minchan Kim 2017-02-27 6:28 ` Minchan Kim 2017-02-27 16:13 ` Shaohua Li 2017-02-27 16:13 ` Shaohua Li 2017-02-27 16:30 ` Michal Hocko 2017-02-27 16:30 ` Michal Hocko 2017-02-28 2:53 ` Minchan Kim 2017-02-28 2:53 ` Minchan Kim 2017-02-27 14:53 ` Michal Hocko 2017-02-27 14:53 ` Michal Hocko 2017-02-27 17:15 ` Johannes Weiner 2017-02-27 17:15 ` Johannes Weiner 2017-02-28 3:19 ` Hillf Danton 2017-02-28 3:19 ` Hillf Danton 2017-02-24 21:31 ` [PATCH V5 4/6] mm: reclaim MADV_FREE pages Shaohua Li 2017-02-24 21:31 ` Shaohua Li 2017-02-27 6:33 ` Minchan Kim 2017-02-27 6:33 ` Minchan Kim 2017-02-27 16:19 ` Shaohua Li 2017-02-27 16:19 ` Shaohua Li 2017-02-27 16:32 ` Michal Hocko 2017-02-27 16:32 ` Michal Hocko 2017-02-28 5:02 ` Minchan Kim 2017-02-28 5:02 ` Minchan Kim 2017-02-27 15:05 ` Michal Hocko 2017-02-27 15:05 ` Michal Hocko 2017-02-27 17:21 ` Johannes Weiner 2017-02-27 17:21 ` Johannes Weiner 2017-02-28 3:21 ` Hillf Danton 2017-02-28 3:21 ` Hillf Danton 2017-02-24 21:31 ` [PATCH V5 5/6] mm: enable MADV_FREE for swapless system Shaohua Li 2017-02-24 21:31 ` Shaohua Li 2017-02-27 15:06 ` Michal Hocko 2017-02-27 15:06 ` Michal Hocko 2017-02-28 3:22 ` Hillf Danton 2017-02-28 3:22 ` Hillf Danton 2017-02-28 5:02 ` Minchan Kim 2017-02-28 5:02 ` Minchan Kim 2017-02-24 21:31 ` [PATCH V5 6/6] proc: show MADV_FREE pages info in smaps Shaohua Li 2017-02-24 21:31 ` Shaohua Li 2017-02-27 15:06 ` Michal Hocko 2017-02-27 15:06 ` Michal Hocko 2017-02-28 3:23 ` Hillf Danton 2017-02-28 3:23 ` Hillf Danton 2017-03-01 13:36 ` Michal Hocko 2017-03-01 13:36 ` Michal Hocko 2017-03-01 17:37 ` Shaohua Li 2017-03-01 17:37 ` Shaohua Li 2017-03-01 17:49 ` Michal Hocko 2017-03-01 17:49 ` Michal Hocko 2017-03-01 18:18 ` Shaohua Li 2017-03-01 18:18 ` Shaohua Li 2017-03-01 18:31 ` Johannes Weiner 2017-03-01 18:31 ` Johannes Weiner 2017-03-01 18:57 ` Michal Hocko 2017-03-01 18:57 ` Michal Hocko 2017-03-02 7:39 ` Minchan Kim 2017-03-02 7:39 ` Minchan Kim 2017-03-02 14:01 ` Johannes Weiner 2017-03-02 14:01 ` Johannes Weiner 2017-03-02 16:30 ` Michal Hocko 2017-03-02 16:30 ` Michal Hocko 2017-03-04 0:10 ` Andrew Morton 2017-03-04 0:10 ` Andrew Morton 2017-03-07 10:05 ` Michal Hocko 2017-03-07 10:05 ` Michal Hocko 2017-03-07 22:43 ` Andrew Morton [this message] 2017-03-07 22:43 ` Andrew Morton 2017-03-08 5:36 ` Minchan Kim 2017-03-08 5:36 ` Minchan Kim
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=20170307144338.023080a8cd600172f37dfe16@linux-foundation.org \ --to=akpm@linux-foundation.org \ --cc=Kernel-team@fb.com \ --cc=hannes@cmpxchg.org \ --cc=hughd@google.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mgorman@techsingularity.net \ --cc=mhocko@kernel.org \ --cc=minchan@kernel.org \ --cc=riel@redhat.com \ --cc=shli@fb.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.