From: Michal Hocko <mhocko@kernel.org> To: Joel Fernandes <joel@joelfernandes.org> Cc: Andrew Morton <akpm@linux-foundation.org>, linux-kernel@vger.kernel.org, Alexey Dobriyan <adobriyan@gmail.com>, Borislav Petkov <bp@alien8.de>, Brendan Gregg <bgregg@netflix.com>, Catalin Marinas <catalin.marinas@arm.com>, Christian Hansen <chansen3@cisco.com>, dancol@google.com, fmayer@google.com, "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>, Jonathan Corbet <corbet@lwn.net>, Kees Cook <keescook@chromium.org>, kernel-team@android.com, linux-api@vger.kernel.org, linux-doc@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, Mike Rapoport <rppt@linux.ibm.com>, minchan@kernel.org, namhyung@google.com, paulmck@linux.ibm.com, Robin Murphy <robin.murphy@arm.com>, Roman Gushchin <guro@fb.com>, Stephen Rothwell <sfr@canb.auug.org.au>, surenb@google.com, Thomas Gleixner <tglx@linutronix.de>, tkjos@google.com, Vladimir Davydov <vdavydov.dev@gmail.com>, Vlastimil Babka <vbabka@suse.cz>, Will Deacon <will@kernel.org> Subject: Re: [PATCH v5 1/6] mm/page_idle: Add per-pid idle page tracking using virtual index Date: Tue, 13 Aug 2019 16:57:48 +0200 [thread overview] Message-ID: <20190813145748.GM17933@dhcp22.suse.cz> (raw) In-Reply-To: <20190813144517.GE258732@google.com> On Tue 13-08-19 10:45:17, Joel Fernandes wrote: > On Tue, Aug 13, 2019 at 04:14:32PM +0200, Michal Hocko wrote: > [snip] > > > > If the API is flawed then this is likely going > > > > to kick us later and will be hard to fix. I am still not convinced about > > > > the swap part of the thing TBH. > > > > > > Ok, then let us discuss it. As I mentioned before, without this we lose the > > > access information due to MADVISE or swapping. Minchan and Konstantin both > > > suggested it that's why I also added it (other than me also realizing that it > > > is neeed). > > > > I have described my concerns about the general idle bit behavior after > > unmapping pointing to discrepancy with !anon pages. And I believe those > > haven't been addressed yet. > > You are referring to this post right? > https://lkml.org/lkml/2019/8/6/637 > > Specifically your question was: > How are you going to handle situation when the page is unmapped and refaulted again (e.g. a normal reclaim of a pagecache)? > > Currently I don't know how to implement that. Would it work if I stored the > page-idle bit information in the pte of the file page (after the page is > unmapped by reclaim?). It would work as long as we keep page tables around after unmap. As they are easily reconstructable this is a good candidate for reclaim as well. > Also, this could be a future extension - the Android heap profiler does not > need it right now. I know that's not a good argument but it is useful to say > that it doesn't affect a real world usecase.. the swap issue on the other > hand, is a real usecase. Since the profiler should not get affected by > swapping or MADVISE_COLD hints. > > > Besides that I am still not seeing any > > description of the usecase that would suffer from the lack of the > > functionality in changelogs. > > You are talking about the swap usecase? The usecase is well layed out in v5 > 2/6. Did you see it? https://lore.kernel.org/patchwork/patch/1112283/ For some reason I've missed it. I will coment on that. -- Michal Hocko SUSE Labs
WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@kernel.org> To: Joel Fernandes <joel@joelfernandes.org> Cc: Andrew Morton <akpm@linux-foundation.org>, linux-kernel@vger.kernel.org, Alexey Dobriyan <adobriyan@gmail.com>, Borislav Petkov <bp@alien8.de>, Brendan Gregg <bgregg@netflix.com>, Catalin Marinas <catalin.marinas@arm.com>, Christian Hansen <chansen3@cisco.com>, dancol@google.com, fmayer@google.com, "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>, Jonathan Corbet <corbet@lwn.net>, Kees Cook <keescook@chromium.org>, kernel-team@android.com, linux-api@vger.kernel.org, linux-doc@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, Mike Rapoport <rppt@linux.ibm.com>, minchan@kernel.org, namhyung@google.com, paulmck@linux.ibm.com, Robin Murphy <robin.murphy@arm.com>, Roman Gushchin <guro@fb.com>, Stephen Rothwell <sfr@canb.a> Subject: Re: [PATCH v5 1/6] mm/page_idle: Add per-pid idle page tracking using virtual index Date: Tue, 13 Aug 2019 16:57:48 +0200 [thread overview] Message-ID: <20190813145748.GM17933@dhcp22.suse.cz> (raw) In-Reply-To: <20190813144517.GE258732@google.com> On Tue 13-08-19 10:45:17, Joel Fernandes wrote: > On Tue, Aug 13, 2019 at 04:14:32PM +0200, Michal Hocko wrote: > [snip] > > > > If the API is flawed then this is likely going > > > > to kick us later and will be hard to fix. I am still not convinced about > > > > the swap part of the thing TBH. > > > > > > Ok, then let us discuss it. As I mentioned before, without this we lose the > > > access information due to MADVISE or swapping. Minchan and Konstantin both > > > suggested it that's why I also added it (other than me also realizing that it > > > is neeed). > > > > I have described my concerns about the general idle bit behavior after > > unmapping pointing to discrepancy with !anon pages. And I believe those > > haven't been addressed yet. > > You are referring to this post right? > https://lkml.org/lkml/2019/8/6/637 > > Specifically your question was: > How are you going to handle situation when the page is unmapped and refaulted again (e.g. a normal reclaim of a pagecache)? > > Currently I don't know how to implement that. Would it work if I stored the > page-idle bit information in the pte of the file page (after the page is > unmapped by reclaim?). It would work as long as we keep page tables around after unmap. As they are easily reconstructable this is a good candidate for reclaim as well. > Also, this could be a future extension - the Android heap profiler does not > need it right now. I know that's not a good argument but it is useful to say > that it doesn't affect a real world usecase.. the swap issue on the other > hand, is a real usecase. Since the profiler should not get affected by > swapping or MADVISE_COLD hints. > > > Besides that I am still not seeing any > > description of the usecase that would suffer from the lack of the > > functionality in changelogs. > > You are talking about the swap usecase? The usecase is well layed out in v5 > 2/6. Did you see it? https://lore.kernel.org/patchwork/patch/1112283/ For some reason I've missed it. I will coment on that. -- Michal Hocko SUSE Labs
next prev parent reply other threads:[~2019-08-13 14:57 UTC|newest] Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-08-07 17:15 [PATCH v5 1/6] mm/page_idle: Add per-pid idle page tracking using virtual index Joel Fernandes (Google) 2019-08-07 17:15 ` Joel Fernandes (Google) 2019-08-07 17:15 ` [PATCH v5 2/6] mm/page_idle: Add support for handling swapped PG_Idle pages Joel Fernandes (Google) 2019-08-07 17:15 ` Joel Fernandes (Google) 2019-08-13 15:04 ` Michal Hocko 2019-08-13 15:04 ` Michal Hocko 2019-08-13 15:36 ` Joel Fernandes 2019-08-13 15:36 ` Joel Fernandes 2019-08-13 19:24 ` Konstantin Khlebnikov 2019-08-13 19:24 ` Konstantin Khlebnikov 2019-08-14 8:05 ` Michal Hocko 2019-08-14 8:05 ` Michal Hocko 2019-08-14 16:32 ` Joel Fernandes 2019-08-14 16:32 ` Joel Fernandes 2019-08-14 18:36 ` Michal Hocko 2019-08-14 18:36 ` Michal Hocko 2019-08-07 17:15 ` [PATCH v5 3/6] [RFC] x86: Add support for idle bit in swap PTE Joel Fernandes (Google) 2019-08-07 17:15 ` Joel Fernandes (Google) 2019-08-07 17:15 ` [PATCH v5 4/6] [RFC] arm64: " Joel Fernandes (Google) 2019-08-07 17:15 ` Joel Fernandes (Google) 2019-08-07 17:15 ` [PATCH v5 5/6] page_idle: Drain all LRU pagevec before idle tracking Joel Fernandes (Google) 2019-08-07 17:15 ` Joel Fernandes (Google) 2019-08-07 17:15 ` [PATCH v5 6/6] doc: Update documentation for page_idle virtual address indexing Joel Fernandes (Google) 2019-08-07 17:15 ` Joel Fernandes (Google) 2019-08-07 20:04 ` [PATCH v5 1/6] mm/page_idle: Add per-pid idle page tracking using virtual index Andrew Morton 2019-08-07 20:04 ` Andrew Morton 2019-08-07 20:45 ` Joel Fernandes 2019-08-07 20:45 ` Joel Fernandes 2019-08-07 20:58 ` Andrew Morton 2019-08-07 20:58 ` Andrew Morton 2019-08-07 21:31 ` Joel Fernandes 2019-08-07 21:31 ` Joel Fernandes 2019-08-07 21:55 ` Joel Fernandes 2019-08-07 21:55 ` Joel Fernandes 2019-08-08 8:00 ` Michal Hocko 2019-08-08 8:00 ` Michal Hocko 2019-08-12 14:56 ` Joel Fernandes 2019-08-12 14:56 ` Joel Fernandes 2019-08-13 9:14 ` Michal Hocko 2019-08-13 9:14 ` Michal Hocko 2019-08-13 13:51 ` Joel Fernandes 2019-08-13 13:51 ` Joel Fernandes 2019-08-13 14:14 ` Michal Hocko 2019-08-13 14:14 ` Michal Hocko 2019-08-13 14:45 ` Joel Fernandes 2019-08-13 14:45 ` Joel Fernandes 2019-08-13 14:57 ` Michal Hocko [this message] 2019-08-13 14:57 ` Michal Hocko 2019-08-12 18:14 ` Jann Horn 2019-08-12 18:14 ` Jann Horn 2019-08-12 18:14 ` Jann Horn 2019-08-13 10:08 ` Michal Hocko 2019-08-13 10:08 ` Michal Hocko 2019-08-13 14:25 ` Joel Fernandes 2019-08-13 14:25 ` Joel Fernandes 2019-08-13 15:19 ` Jann Horn 2019-08-13 15:19 ` Jann Horn 2019-08-13 15:19 ` Jann Horn 2019-08-13 15:29 ` Jann Horn 2019-08-13 15:29 ` Jann Horn 2019-08-13 15:29 ` Jann Horn 2019-08-13 15:34 ` Daniel Gruss 2019-08-13 15:34 ` Daniel Gruss 2019-08-13 19:18 ` Joel Fernandes 2019-08-13 19:18 ` Joel Fernandes 2019-08-14 7:56 ` Michal Hocko 2019-08-14 7:56 ` Michal Hocko 2019-08-19 21:52 ` Joel Fernandes 2019-08-19 21:52 ` Joel Fernandes 2019-08-13 15:30 ` Joel Fernandes 2019-08-13 15:30 ` Joel Fernandes 2019-08-13 15:40 ` Jann Horn 2019-08-13 15:40 ` Jann Horn 2019-08-13 15:40 ` Jann Horn
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=20190813145748.GM17933@dhcp22.suse.cz \ --to=mhocko@kernel.org \ --cc=adobriyan@gmail.com \ --cc=akpm@linux-foundation.org \ --cc=bgregg@netflix.com \ --cc=bp@alien8.de \ --cc=catalin.marinas@arm.com \ --cc=chansen3@cisco.com \ --cc=corbet@lwn.net \ --cc=dancol@google.com \ --cc=fmayer@google.com \ --cc=guro@fb.com \ --cc=hpa@zytor.com \ --cc=joel@joelfernandes.org \ --cc=keescook@chromium.org \ --cc=kernel-team@android.com \ --cc=linux-api@vger.kernel.org \ --cc=linux-doc@vger.kernel.org \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=minchan@kernel.org \ --cc=mingo@redhat.com \ --cc=namhyung@google.com \ --cc=paulmck@linux.ibm.com \ --cc=robin.murphy@arm.com \ --cc=rppt@linux.ibm.com \ --cc=sfr@canb.auug.org.au \ --cc=surenb@google.com \ --cc=tglx@linutronix.de \ --cc=tkjos@google.com \ --cc=vbabka@suse.cz \ --cc=vdavydov.dev@gmail.com \ --cc=will@kernel.org \ /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.