From: Joel Fernandes (Google) <hidden> Date: 2019-08-05 17:05:07
The page_idle tracking feature currently requires looking up the pagemap
for a process followed by interacting with /sys/kernel/mm/page_idle.
Looking up PFN from pagemap in Android devices is not supported by
unprivileged process and requires SYS_ADMIN and gives 0 for the PFN.
This patch adds support to directly interact with page_idle tracking at
the PID level by introducing a /proc/<pid>/page_idle file. It follows
the exact same semantics as the global /sys/kernel/mm/page_idle, but now
looking up PFN through pagemap is not needed since the interface uses
virtual frame numbers, and at the same time also does not require
SYS_ADMIN.
In Android, we are using this for the heap profiler (heapprofd) which
profiles and pin points code paths which allocates and leaves memory
idle for long periods of time. This method solves the security issue
with userspace learning the PFN, and while at it is also shown to yield
better results than the pagemap lookup, the theory being that the window
where the address space can change is reduced by eliminating the
intermediate pagemap look up stage. In virtual address indexing, the
process's mmap_sem is held for the duration of the access.
Signed-off-by: Joel Fernandes (Google) <redacted>
---
v3->v4: Minor fixups (Minchan)
Add swap pte handling (Konstantin, Minchan)
v2->v3:
Fixed a bug where I was doing a kfree that is not needed due to not
needing to do GFP_ATOMIC allocations.
v1->v2:
Mark swap ptes as idle (Minchan)
Avoid need for GFP_ATOMIC (Andrew)
Get rid of idle_page_list lock by moving list to stack
Internal review -> v1:
Fixes from Suren.
Corrections to change log, docs (Florian, Sandeep)
arch/Kconfig | 3 +
fs/proc/base.c | 3 +
fs/proc/internal.h | 1 +
fs/proc/task_mmu.c | 43 ++++
include/asm-generic/pgtable.h | 6 +
include/linux/page_idle.h | 4 +
mm/page_idle.c | 359 +++++++++++++++++++++++++++++-----
mm/rmap.c | 2 +
8 files changed, 376 insertions(+), 45 deletions(-)
@@ -51,6 +51,18 @@ static struct page *page_idle_get_page(unsigned long pfn)returnpage;}+/*+*Thisfunctiontriestogetausermemorypagebypfnasdescribedabove.+*/+staticstructpage*page_idle_get_page_pfn(unsignedlongpfn)+{++if(!pfn_valid(pfn))+returnNULL;++returnpage_idle_get_page(pfn_to_page(pfn));+}+staticboolpage_idle_clear_pte_refs_one(structpage*page,structvm_area_struct*vma,unsignedlongaddr,void*arg)
@@ -118,6 +130,47 @@ static void page_idle_clear_pte_refs(struct page *page)unlock_page(page);}+/* Helper to get the start and end frame given a pos and count */+staticintpage_idle_get_frames(loff_tpos,size_tcount,structmm_struct*mm,+unsignedlong*start,unsignedlong*end)+{+unsignedlongmax_frame;++/* If an mm is not given, assume we want physical frames */+max_frame=mm?(mm->task_size>>PAGE_SHIFT):max_pfn;++if(pos%BITMAP_CHUNK_SIZE||count%BITMAP_CHUNK_SIZE)+return-EINVAL;++*start=pos*BITS_PER_BYTE;+if(*start>=max_frame)+return-ENXIO;++*end=*start+count*BITS_PER_BYTE;+if(*end>max_frame)+*end=max_frame;+return0;+}++staticboolpage_idle_pte_check(structpage*page)+{+if(!page)+returnfalse;++if(page_is_idle(page)){+/*+*Thepagemighthavebeenreferencedviaa+*pte,inwhichcaseitisnotidle.Clear+*refsandrecheck.+*/+page_idle_clear_pte_refs(page);+if(page_is_idle(page))+returntrue;+}++returnfalse;+}+staticssize_tpage_idle_bitmap_read(structfile*file,structkobject*kobj,structbin_attribute*attr,char*buf,loff_tpos,size_tcount)
From: Joel Fernandes (Google) <hidden> Date: 2019-08-05 17:05:18
During idle tracking, we see that sometimes faulted anon pages are in
pagevec but are not drained to LRU. Idle tracking considers pages only
on LRU. Drain all CPU's LRU before starting idle tracking.
Signed-off-by: Joel Fernandes (Google) <redacted>
---
mm/page_idle.c | 6 ++++++
1 file changed, 6 insertions(+)
@@ -19,10 +19,14 @@ It is enabled by CONFIG_IDLE_PAGE_TRACKING=y. User API ========+There are 2 ways to access the idle page tracking API. One uses physical+address indexing, another uses a simpler virtual address indexing scheme.-The idle page tracking API is located at ``/sys/kernel/mm/page_idle``.-Currently, it consists of the only read-write file,-``/sys/kernel/mm/page_idle/bitmap``.+Physical address indexing+-------------------------+The idle page tracking API for physical address indexing using page frame+numbers (PFN) is located at ``/sys/kernel/mm/page_idle``. Currently, it+consists of the only read-write file, ``/sys/kernel/mm/page_idle/bitmap``. The file implements a bitmap where each bit corresponds to a memory page. The bitmap is represented by an array of 8-byte integers, and the page at PFN #i is
@@ -74,6 +78,31 @@ See :ref:`Documentation/admin-guide/mm/pagemap.rst <pagemap>` for more information about ``/proc/pid/pagemap``, ``/proc/kpageflags``, and``/proc/kpagecgroup``.+Virtual address indexing+------------------------+The idle page tracking API for virtual address indexing using virtual frame+numbers (VFN) for a process ``<pid>`` is located at ``/proc/<pid>/page_idle``.+It is a bitmap that follows the same semantics as+``/sys/kernel/mm/page_idle/bitmap`` except that it uses virtual instead of+physical frame numbers.++This idle page tracking API does not deal with PFN so it does not require prior+lookups of ``pagemap``. This is an advantage on some systems where looking up+PFN is considered a security issue. Also in some cases, this interface could+be slightly more reliable to use than physical address indexing, since in+physical address indexing, address space changes can occur between reading the+``pagemap`` and reading the ``bitmap``, while in virtual address indexing, the+process's ``mmap_sem`` is held for the duration of the access.++To estimate the amount of pages that are not used by a workload one should:++1. Mark all the workload's pages as idle by setting corresponding bits in+``/proc/<pid>/page_idle``.++2. Wait until the workload accesses its working set.++3. Read ``/proc/<pid>/page_idle`` and count the number of bits set.+.._impl_details: Implementation Details
@@ -99,10 +128,10 @@ When a dirty page is written to swap or disk as a result of memory reclaim or exceeding the dirty memory limit, it is not marked referenced. The idle memory tracking feature adds a new page flag, the Idle flag. This flag-is set manually, by writing to ``/sys/kernel/mm/page_idle/bitmap`` (see the-:ref:`User API <user_api>`-section), and cleared automatically whenever a page is referenced as defined-above.+is set manually, by writing to ``/sys/kernel/mm/page_idle/bitmap`` for physical+addressing or by writing to ``/proc/<pid>/page_idle`` for virtual+addressing (see the :ref:`User API <user_api>` section), and cleared+automatically whenever a page is referenced as defined above. When a page is marked idle, the Accessed bit must be cleared in all PTEs it is mapped to, otherwise we will not be able to detect accesses to the page coming
From: Joel Fernandes (Google) <hidden> Date: 2019-08-05 17:05:28
This bit will be used by idle page tracking code to correctly identify
if a page that was swapped out was idle before it got swapped out.
Without this PTE bit, we lose information about if a page is idle or not
since the page frame gets unmapped.
In this patch we reuse PTE_DEVMAP bit since idle page tracking only
works on user pages in the LRU. Device pages should not consitute those
so it should be unused and safe to use.
Cc: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Joel Fernandes (Google) <redacted>
---
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/pgtable-prot.h | 1 +
arch/arm64/include/asm/pgtable.h | 15 +++++++++++++++
3 files changed, 17 insertions(+)
From: Joel Fernandes (Google) <hidden> Date: 2019-08-05 17:05:29
This bit will be used by idle page tracking code to correctly identify
if a page that was swapped out was idle before it got swapped out.
Without this PTE bit, we lose information about if a page is idle or not
since the page frame gets unmapped and the page gets freed.
Bits 2-6 are unused in the swap PTE (see the comment in
arch/x86/include/asm/pgtable_64.h). Bit 2 corresponds to _PAGE_USER. Use
it for swap PTE purposes.
Signed-off-by: Joel Fernandes (Google) <redacted>
---
arch/x86/Kconfig | 1 +
arch/x86/include/asm/pgtable.h | 15 +++++++++++++++
arch/x86/include/asm/pgtable_types.h | 6 ++++++
3 files changed, 22 insertions(+)
From: Michal Hocko <mhocko@kernel.org> Date: 2019-08-06 08:42:13
On Mon 05-08-19 13:04:49, Joel Fernandes (Google) wrote:
This bit will be used by idle page tracking code to correctly identify
if a page that was swapped out was idle before it got swapped out.
Without this PTE bit, we lose information about if a page is idle or not
since the page frame gets unmapped.
And why do we need that? Why cannot we simply assume all swapped out
pages to be idle? They were certainly idle enough to be reclaimed,
right? Or what does idle actualy mean here?
quoted hunk
In this patch we reuse PTE_DEVMAP bit since idle page tracking only
works on user pages in the LRU. Device pages should not consitute those
so it should be unused and safe to use.
Cc: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Joel Fernandes (Google) <redacted>
---
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/pgtable-prot.h | 1 +
arch/arm64/include/asm/pgtable.h | 15 +++++++++++++++
3 files changed, 17 insertions(+)
From: Michal Hocko <mhocko@kernel.org> Date: 2019-08-06 08:44:11
On Mon 05-08-19 13:04:50, Joel Fernandes (Google) wrote:
During idle tracking, we see that sometimes faulted anon pages are in
pagevec but are not drained to LRU. Idle tracking considers pages only
on LRU. Drain all CPU's LRU before starting idle tracking.
Please expand on why does this matter enough to introduce a potentially
expensinve draining which has to schedule a work on each CPU and wait
for them to finish.
From: Michal Hocko <mhocko@kernel.org> Date: 2019-08-06 08:56:14
On Mon 05-08-19 13:04:47, Joel Fernandes (Google) wrote:
The page_idle tracking feature currently requires looking up the pagemap
for a process followed by interacting with /sys/kernel/mm/page_idle.
Looking up PFN from pagemap in Android devices is not supported by
unprivileged process and requires SYS_ADMIN and gives 0 for the PFN.
This patch adds support to directly interact with page_idle tracking at
the PID level by introducing a /proc/<pid>/page_idle file. It follows
the exact same semantics as the global /sys/kernel/mm/page_idle, but now
looking up PFN through pagemap is not needed since the interface uses
virtual frame numbers, and at the same time also does not require
SYS_ADMIN.
In Android, we are using this for the heap profiler (heapprofd) which
profiles and pin points code paths which allocates and leaves memory
idle for long periods of time. This method solves the security issue
with userspace learning the PFN, and while at it is also shown to yield
better results than the pagemap lookup, the theory being that the window
where the address space can change is reduced by eliminating the
intermediate pagemap look up stage. In virtual address indexing, the
process's mmap_sem is held for the duration of the access.
As already mentioned in one of the previous versions. The interface
seems sane and the usecase as well. So I do not really have high level
objections.
From a quick look at the patch I would just object to pulling swap idle
tracking into this patch because it makes the review harder and it is
essentially a dead code until a later patch. I am also not sure whether
that is really necessary and it really begs for an explicit
justification.
I will try to go through the patch more carefully later as time allows.
From: Joel Fernandes <hidden> Date: 2019-08-06 10:36:36
On Tue, Aug 06, 2019 at 10:42:03AM +0200, Michal Hocko wrote:
On Mon 05-08-19 13:04:49, Joel Fernandes (Google) wrote:
quoted
This bit will be used by idle page tracking code to correctly identify
if a page that was swapped out was idle before it got swapped out.
Without this PTE bit, we lose information about if a page is idle or not
since the page frame gets unmapped.
And why do we need that? Why cannot we simply assume all swapped out
pages to be idle? They were certainly idle enough to be reclaimed,
right? Or what does idle actualy mean here?
Yes, but other than swapping, in Android a page can be forced to be swapped
out as well using the new hints that Minchan is adding?
Also, even if they were idle enough to be swapped, there is a chance that they
were marked as idle and *accessed* before the swapping. Due to swapping, the
"page was accessed since we last marked it as idle" information is lost. I am
able to verify this.
Idle in this context means the same thing as in page idle tracking terms, the
page was not accessed by userspace since we last marked it as idle (using
/proc/<pid>/page_idle).
thanks,
- Joel
quoted
In this patch we reuse PTE_DEVMAP bit since idle page tracking only
works on user pages in the LRU. Device pages should not consitute those
so it should be unused and safe to use.
Cc: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Joel Fernandes (Google) <redacted>
---
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/pgtable-prot.h | 1 +
arch/arm64/include/asm/pgtable.h | 15 +++++++++++++++
3 files changed, 17 insertions(+)
From: Joel Fernandes <hidden> Date: 2019-08-06 10:46:01
On Tue, Aug 06, 2019 at 10:43:57AM +0200, Michal Hocko wrote:
On Mon 05-08-19 13:04:50, Joel Fernandes (Google) wrote:
quoted
During idle tracking, we see that sometimes faulted anon pages are in
pagevec but are not drained to LRU. Idle tracking considers pages only
on LRU. Drain all CPU's LRU before starting idle tracking.
Please expand on why does this matter enough to introduce a potentially
expensinve draining which has to schedule a work on each CPU and wait
for them to finish.
Sure, I can expand. I am able to find multiple issues involving this. One
issue looks like idle tracking is completely broken. It shows up in my
testing as if a page that is marked as idle is always "accessed" -- because
it was never marked as idle (due to not draining of pagevec).
The other issue shows up as a failure in my "swap test", with the following
sequence:
1. Allocate some pages
2. Write to them
3. Mark them as idle <--- fails
4. Introduce some memory pressure to induce swapping.
5. Check the swap bit I introduced in this series. <--- fails to set idle
bit in swap PTE.
Draining the pagevec in advance fixes both of these issues.
This operation even if expensive is only done once during the access of the
page_idle file. Did you have a better fix in mind?
thanks,
- Joel
From: Joel Fernandes <hidden> Date: 2019-08-06 10:47:23
On Tue, Aug 06, 2019 at 10:56:05AM +0200, Michal Hocko wrote:
On Mon 05-08-19 13:04:47, Joel Fernandes (Google) wrote:
quoted
The page_idle tracking feature currently requires looking up the pagemap
for a process followed by interacting with /sys/kernel/mm/page_idle.
Looking up PFN from pagemap in Android devices is not supported by
unprivileged process and requires SYS_ADMIN and gives 0 for the PFN.
This patch adds support to directly interact with page_idle tracking at
the PID level by introducing a /proc/<pid>/page_idle file. It follows
the exact same semantics as the global /sys/kernel/mm/page_idle, but now
looking up PFN through pagemap is not needed since the interface uses
virtual frame numbers, and at the same time also does not require
SYS_ADMIN.
In Android, we are using this for the heap profiler (heapprofd) which
profiles and pin points code paths which allocates and leaves memory
idle for long periods of time. This method solves the security issue
with userspace learning the PFN, and while at it is also shown to yield
better results than the pagemap lookup, the theory being that the window
where the address space can change is reduced by eliminating the
intermediate pagemap look up stage. In virtual address indexing, the
process's mmap_sem is held for the duration of the access.
As already mentioned in one of the previous versions. The interface
seems sane and the usecase as well. So I do not really have high level
objections.
That is great to know.
From a quick look at the patch I would just object to pulling swap idle
tracking into this patch because it makes the review harder and it is
essentially a dead code until a later patch. I am also not sure whether
that is really necessary and it really begs for an explicit
justification.
Ok I will split it out, and also expand on the need for it a bit more.
I will try to go through the patch more carefully later as time allows.
From: Michal Hocko <mhocko@kernel.org> Date: 2019-08-06 10:48:03
On Tue 06-08-19 06:36:27, Joel Fernandes wrote:
On Tue, Aug 06, 2019 at 10:42:03AM +0200, Michal Hocko wrote:
quoted
On Mon 05-08-19 13:04:49, Joel Fernandes (Google) wrote:
quoted
This bit will be used by idle page tracking code to correctly identify
if a page that was swapped out was idle before it got swapped out.
Without this PTE bit, we lose information about if a page is idle or not
since the page frame gets unmapped.
And why do we need that? Why cannot we simply assume all swapped out
pages to be idle? They were certainly idle enough to be reclaimed,
right? Or what does idle actualy mean here?
Yes, but other than swapping, in Android a page can be forced to be swapped
out as well using the new hints that Minchan is adding?
Yes and that is effectivelly making them idle, no?
Also, even if they were idle enough to be swapped, there is a chance that they
were marked as idle and *accessed* before the swapping. Due to swapping, the
"page was accessed since we last marked it as idle" information is lost. I am
able to verify this.
Idle in this context means the same thing as in page idle tracking terms, the
page was not accessed by userspace since we last marked it as idle (using
/proc/<pid>/page_idle).
Please describe a usecase and why that information might be useful.
--
Michal Hocko
SUSE Labs
From: Michal Hocko <mhocko@kernel.org> Date: 2019-08-06 10:51:57
On Tue 06-08-19 06:45:54, Joel Fernandes wrote:
On Tue, Aug 06, 2019 at 10:43:57AM +0200, Michal Hocko wrote:
quoted
On Mon 05-08-19 13:04:50, Joel Fernandes (Google) wrote:
quoted
During idle tracking, we see that sometimes faulted anon pages are in
pagevec but are not drained to LRU. Idle tracking considers pages only
on LRU. Drain all CPU's LRU before starting idle tracking.
Please expand on why does this matter enough to introduce a potentially
expensinve draining which has to schedule a work on each CPU and wait
for them to finish.
Sure, I can expand. I am able to find multiple issues involving this. One
issue looks like idle tracking is completely broken. It shows up in my
testing as if a page that is marked as idle is always "accessed" -- because
it was never marked as idle (due to not draining of pagevec).
The other issue shows up as a failure in my "swap test", with the following
sequence:
1. Allocate some pages
2. Write to them
3. Mark them as idle <--- fails
4. Introduce some memory pressure to induce swapping.
5. Check the swap bit I introduced in this series. <--- fails to set idle
bit in swap PTE.
Draining the pagevec in advance fixes both of these issues.
This belongs to the changelog.
This operation even if expensive is only done once during the access of the
page_idle file. Did you have a better fix in mind?
Can we set the idle bit also for non-lru pages as long as they are
reachable via pte?
--
Michal Hocko
SUSE Labs
From: Minchan Kim <minchan@kernel.org> Date: 2019-08-06 11:07:53
On Tue, Aug 06, 2019 at 12:47:55PM +0200, Michal Hocko wrote:
On Tue 06-08-19 06:36:27, Joel Fernandes wrote:
quoted
On Tue, Aug 06, 2019 at 10:42:03AM +0200, Michal Hocko wrote:
quoted
On Mon 05-08-19 13:04:49, Joel Fernandes (Google) wrote:
quoted
This bit will be used by idle page tracking code to correctly identify
if a page that was swapped out was idle before it got swapped out.
Without this PTE bit, we lose information about if a page is idle or not
since the page frame gets unmapped.
And why do we need that? Why cannot we simply assume all swapped out
pages to be idle? They were certainly idle enough to be reclaimed,
right? Or what does idle actualy mean here?
Yes, but other than swapping, in Android a page can be forced to be swapped
out as well using the new hints that Minchan is adding?
Yes and that is effectivelly making them idle, no?
1. mark page-A idle which was present at that time.
2. run workload
3. page-A is touched several times
4. *sudden* memory pressure happen so finally page A is finally swapped out
5. now see the page A idle - but it's incorrect.
From: Joel Fernandes <hidden> Date: 2019-08-06 11:14:54
On Tue, Aug 06, 2019 at 12:47:55PM +0200, Michal Hocko wrote:
On Tue 06-08-19 06:36:27, Joel Fernandes wrote:
quoted
On Tue, Aug 06, 2019 at 10:42:03AM +0200, Michal Hocko wrote:
quoted
On Mon 05-08-19 13:04:49, Joel Fernandes (Google) wrote:
quoted
This bit will be used by idle page tracking code to correctly identify
if a page that was swapped out was idle before it got swapped out.
Without this PTE bit, we lose information about if a page is idle or not
since the page frame gets unmapped.
And why do we need that? Why cannot we simply assume all swapped out
pages to be idle? They were certainly idle enough to be reclaimed,
right? Or what does idle actualy mean here?
Yes, but other than swapping, in Android a page can be forced to be swapped
out as well using the new hints that Minchan is adding?
Yes and that is effectivelly making them idle, no?
That depends on how you think of it. If you are thinking of a monitoring
process like a heap profiler, then from the heap profiler's (that only cares
about the process it is monitoring) perspective it will look extremely odd if
pages that are recently accessed by the process appear to be idle which would
falsely look like those processes are leaking memory. The reality being,
Android forced those pages into swap because of other reasons. I would like
for the swapping mechanism, whether forced swapping or memory reclaim, not to
interfere with the idle detection.
This is just an effort to make the idle tracking a little bit better. We
would like to not lose the 'accessed' information of the pages.
Initially, I had proposed what you are suggesting as well however the above
reasons made me to do it like this. Also Minchan and Konstantin suggested
this, so there are more people interested in the swap idle bit. Minchan, can
you provide more thoughts here? (He is on 2-week vacation from today so
hopefully replies before he vanishes ;-)).
Also assuming all swap pages as idle has other "semantic" issues. It is quite
odd if a swapped page is automatically marked as idle without userspace
telling it to. Consider the following set of events: 1. Userspace marks only
a certain memory region as idle. 2. Userspace reads back the bits
corresponding to a bigger region. Part of this bigger region is swapped.
Userspace expects all of the pages it did not mark, to have idle bit set to
'0' because it never marked them as idle. However if it is now surprised by
what it read back (not all '0' read back). Since a page is swapped, it will
be now marked "automatically" as idle as per your proposal, even if userspace
never marked it explicity before. This would be quite confusing/ambiguous.
I will include this and other information in future commit messages.
thanks,
- Joel
From: Michal Hocko <mhocko@kernel.org> Date: 2019-08-06 11:14:59
On Tue 06-08-19 20:07:37, Minchan Kim wrote:
On Tue, Aug 06, 2019 at 12:47:55PM +0200, Michal Hocko wrote:
quoted
On Tue 06-08-19 06:36:27, Joel Fernandes wrote:
quoted
On Tue, Aug 06, 2019 at 10:42:03AM +0200, Michal Hocko wrote:
quoted
On Mon 05-08-19 13:04:49, Joel Fernandes (Google) wrote:
quoted
This bit will be used by idle page tracking code to correctly identify
if a page that was swapped out was idle before it got swapped out.
Without this PTE bit, we lose information about if a page is idle or not
since the page frame gets unmapped.
And why do we need that? Why cannot we simply assume all swapped out
pages to be idle? They were certainly idle enough to be reclaimed,
right? Or what does idle actualy mean here?
Yes, but other than swapping, in Android a page can be forced to be swapped
out as well using the new hints that Minchan is adding?
Yes and that is effectivelly making them idle, no?
1. mark page-A idle which was present at that time.
2. run workload
3. page-A is touched several times
4. *sudden* memory pressure happen so finally page A is finally swapped out
5. now see the page A idle - but it's incorrect.
Could you expand on what you mean by idle exactly? Why pageout doesn't
really qualify as "mark-idle and reclaim"? Also could you describe a
usecase where the swapout distinction really matters and it would lead
to incorrect behavior?
--
Michal Hocko
SUSE Labs
From: Joel Fernandes <hidden> Date: 2019-08-06 11:19:30
On Tue, Aug 06, 2019 at 12:51:49PM +0200, Michal Hocko wrote:
On Tue 06-08-19 06:45:54, Joel Fernandes wrote:
quoted
On Tue, Aug 06, 2019 at 10:43:57AM +0200, Michal Hocko wrote:
quoted
On Mon 05-08-19 13:04:50, Joel Fernandes (Google) wrote:
quoted
During idle tracking, we see that sometimes faulted anon pages are in
pagevec but are not drained to LRU. Idle tracking considers pages only
on LRU. Drain all CPU's LRU before starting idle tracking.
Please expand on why does this matter enough to introduce a potentially
expensinve draining which has to schedule a work on each CPU and wait
for them to finish.
Sure, I can expand. I am able to find multiple issues involving this. One
issue looks like idle tracking is completely broken. It shows up in my
testing as if a page that is marked as idle is always "accessed" -- because
it was never marked as idle (due to not draining of pagevec).
The other issue shows up as a failure in my "swap test", with the following
sequence:
1. Allocate some pages
2. Write to them
3. Mark them as idle <--- fails
4. Introduce some memory pressure to induce swapping.
5. Check the swap bit I introduced in this series. <--- fails to set idle
bit in swap PTE.
Draining the pagevec in advance fixes both of these issues.
This belongs to the changelog.
Sure, will add.
quoted
This operation even if expensive is only done once during the access of the
page_idle file. Did you have a better fix in mind?
Can we set the idle bit also for non-lru pages as long as they are
reachable via pte?
Not at the moment with the current page idle tracking code. PageLRU(page)
flag is checked in page_idle_get_page().
Even if we could set it for non-LRU, the idle bit (page flag) would not be
cleared if page is not on LRU because page-reclaim code (page_referenced() I
believe) would not clear it. This whole mechanism depends on page-reclaim. Or
did I miss your point?
thanks,
- Joel
From: Joel Fernandes <hidden> Date: 2019-08-06 11:26:11
On Tue, Aug 06, 2019 at 01:14:52PM +0200, Michal Hocko wrote:
On Tue 06-08-19 20:07:37, Minchan Kim wrote:
quoted
On Tue, Aug 06, 2019 at 12:47:55PM +0200, Michal Hocko wrote:
quoted
On Tue 06-08-19 06:36:27, Joel Fernandes wrote:
quoted
On Tue, Aug 06, 2019 at 10:42:03AM +0200, Michal Hocko wrote:
quoted
On Mon 05-08-19 13:04:49, Joel Fernandes (Google) wrote:
quoted
This bit will be used by idle page tracking code to correctly identify
if a page that was swapped out was idle before it got swapped out.
Without this PTE bit, we lose information about if a page is idle or not
since the page frame gets unmapped.
And why do we need that? Why cannot we simply assume all swapped out
pages to be idle? They were certainly idle enough to be reclaimed,
right? Or what does idle actualy mean here?
Yes, but other than swapping, in Android a page can be forced to be swapped
out as well using the new hints that Minchan is adding?
Yes and that is effectivelly making them idle, no?
1. mark page-A idle which was present at that time.
2. run workload
3. page-A is touched several times
4. *sudden* memory pressure happen so finally page A is finally swapped out
5. now see the page A idle - but it's incorrect.
Could you expand on what you mean by idle exactly? Why pageout doesn't
really qualify as "mark-idle and reclaim"? Also could you describe a
usecase where the swapout distinction really matters and it would lead
to incorrect behavior?
From: Michal Hocko <mhocko@kernel.org> Date: 2019-08-06 11:44:12
On Tue 06-08-19 07:19:21, Joel Fernandes wrote:
On Tue, Aug 06, 2019 at 12:51:49PM +0200, Michal Hocko wrote:
quoted
On Tue 06-08-19 06:45:54, Joel Fernandes wrote:
quoted
On Tue, Aug 06, 2019 at 10:43:57AM +0200, Michal Hocko wrote:
quoted
On Mon 05-08-19 13:04:50, Joel Fernandes (Google) wrote:
quoted
During idle tracking, we see that sometimes faulted anon pages are in
pagevec but are not drained to LRU. Idle tracking considers pages only
on LRU. Drain all CPU's LRU before starting idle tracking.
Please expand on why does this matter enough to introduce a potentially
expensinve draining which has to schedule a work on each CPU and wait
for them to finish.
Sure, I can expand. I am able to find multiple issues involving this. One
issue looks like idle tracking is completely broken. It shows up in my
testing as if a page that is marked as idle is always "accessed" -- because
it was never marked as idle (due to not draining of pagevec).
The other issue shows up as a failure in my "swap test", with the following
sequence:
1. Allocate some pages
2. Write to them
3. Mark them as idle <--- fails
4. Introduce some memory pressure to induce swapping.
5. Check the swap bit I introduced in this series. <--- fails to set idle
bit in swap PTE.
Draining the pagevec in advance fixes both of these issues.
This belongs to the changelog.
Sure, will add.
quoted
quoted
This operation even if expensive is only done once during the access of the
page_idle file. Did you have a better fix in mind?
Can we set the idle bit also for non-lru pages as long as they are
reachable via pte?
Not at the moment with the current page idle tracking code. PageLRU(page)
flag is checked in page_idle_get_page().
yes, I am aware of the current code. I strongly suspect that the PageLRU
check was there to not mark arbitrary page looked up by pfn with the
idle bit because that would be unexpected. But I might be easily wrong
here.
Even if we could set it for non-LRU, the idle bit (page flag) would not be
cleared if page is not on LRU because page-reclaim code (page_referenced() I
believe) would not clear it.
Yes, it is either reclaim when checking references as you say but also
mark_page_accessed. I believe the later might still have the page on the
pcp LRU add cache. Maybe I am missing something something but it seems
that there is nothing fundamentally requiring the user mapped page to be
on the LRU list when seting the idle bit.
That being said, your big hammer approach will work more reliable but if
you do not feel like changing the underlying PageLRU assumption then
document that draining should be removed longterm.
--
Michal Hocko
SUSE Labs
From: Michal Hocko <mhocko@kernel.org> Date: 2019-08-06 11:57:13
On Tue 06-08-19 07:14:46, Joel Fernandes wrote:
On Tue, Aug 06, 2019 at 12:47:55PM +0200, Michal Hocko wrote:
quoted
On Tue 06-08-19 06:36:27, Joel Fernandes wrote:
quoted
On Tue, Aug 06, 2019 at 10:42:03AM +0200, Michal Hocko wrote:
quoted
On Mon 05-08-19 13:04:49, Joel Fernandes (Google) wrote:
quoted
This bit will be used by idle page tracking code to correctly identify
if a page that was swapped out was idle before it got swapped out.
Without this PTE bit, we lose information about if a page is idle or not
since the page frame gets unmapped.
And why do we need that? Why cannot we simply assume all swapped out
pages to be idle? They were certainly idle enough to be reclaimed,
right? Or what does idle actualy mean here?
Yes, but other than swapping, in Android a page can be forced to be swapped
out as well using the new hints that Minchan is adding?
Yes and that is effectivelly making them idle, no?
That depends on how you think of it.
I would much prefer to have it documented so that I do not have to guess ;)
If you are thinking of a monitoring
process like a heap profiler, then from the heap profiler's (that only cares
about the process it is monitoring) perspective it will look extremely odd if
pages that are recently accessed by the process appear to be idle which would
falsely look like those processes are leaking memory. The reality being,
Android forced those pages into swap because of other reasons. I would like
for the swapping mechanism, whether forced swapping or memory reclaim, not to
interfere with the idle detection.
Hmm, but how are you going to handle situation when the page is unmapped
and refaulted again (e.g. a normal reclaim of a pagecache)? You are
losing that information same was as in the swapout case, no? Or am I
missing something?
This is just an effort to make the idle tracking a little bit better. We
would like to not lose the 'accessed' information of the pages.
Initially, I had proposed what you are suggesting as well however the above
reasons made me to do it like this. Also Minchan and Konstantin suggested
this, so there are more people interested in the swap idle bit. Minchan, can
you provide more thoughts here? (He is on 2-week vacation from today so
hopefully replies before he vanishes ;-)).
We can move on with the rest of the series in the mean time but I would
like to see a proper justification for the swap entries and why they
should be handled special.
Also assuming all swap pages as idle has other "semantic" issues. It is quite
odd if a swapped page is automatically marked as idle without userspace
telling it to. Consider the following set of events: 1. Userspace marks only
a certain memory region as idle. 2. Userspace reads back the bits
corresponding to a bigger region. Part of this bigger region is swapped.
Userspace expects all of the pages it did not mark, to have idle bit set to
'0' because it never marked them as idle. However if it is now surprised by
what it read back (not all '0' read back). Since a page is swapped, it will
be now marked "automatically" as idle as per your proposal, even if userspace
never marked it explicity before. This would be quite confusing/ambiguous.
OK, I see. I guess the primary question I have is how do you distinguish
Idle page which got unmapped and faulted in again from swapped out page
and refaulted - including the time the pte is not present.
--
Michal Hocko
SUSE Labs
From: Joel Fernandes <hidden> Date: 2019-08-06 13:44:03
On Tue, Aug 06, 2019 at 01:57:03PM +0200, Michal Hocko wrote:
On Tue 06-08-19 07:14:46, Joel Fernandes wrote:
quoted
On Tue, Aug 06, 2019 at 12:47:55PM +0200, Michal Hocko wrote:
quoted
On Tue 06-08-19 06:36:27, Joel Fernandes wrote:
quoted
On Tue, Aug 06, 2019 at 10:42:03AM +0200, Michal Hocko wrote:
quoted
On Mon 05-08-19 13:04:49, Joel Fernandes (Google) wrote:
quoted
This bit will be used by idle page tracking code to correctly identify
if a page that was swapped out was idle before it got swapped out.
Without this PTE bit, we lose information about if a page is idle or not
since the page frame gets unmapped.
And why do we need that? Why cannot we simply assume all swapped out
pages to be idle? They were certainly idle enough to be reclaimed,
right? Or what does idle actualy mean here?
Yes, but other than swapping, in Android a page can be forced to be swapped
out as well using the new hints that Minchan is adding?
Yes and that is effectivelly making them idle, no?
That depends on how you think of it.
I would much prefer to have it documented so that I do not have to guess ;)
Sure :)
quoted
If you are thinking of a monitoring
process like a heap profiler, then from the heap profiler's (that only cares
about the process it is monitoring) perspective it will look extremely odd if
pages that are recently accessed by the process appear to be idle which would
falsely look like those processes are leaking memory. The reality being,
Android forced those pages into swap because of other reasons. I would like
for the swapping mechanism, whether forced swapping or memory reclaim, not to
interfere with the idle detection.
Hmm, but how are you going to handle situation when the page is unmapped
and refaulted again (e.g. a normal reclaim of a pagecache)? You are
losing that information same was as in the swapout case, no? Or am I
missing something?
Yes you are right, it would have the same issue, thanks for bringing it up.
Should we rename this bit to PTE_IDLE and do the same thing that we are doing
for swap?
i.e. if (page_idle(page)) and page is a file page, then we write state
into the PTE of the page. Later on refault, the PTE bit would automatically
get cleared (just like it does on swap-in). But before refault, the idle
tracking code sees the page as still marked idle. Do you see any issue with that?
quoted
This is just an effort to make the idle tracking a little bit better. We
would like to not lose the 'accessed' information of the pages.
Initially, I had proposed what you are suggesting as well however the above
reasons made me to do it like this. Also Minchan and Konstantin suggested
this, so there are more people interested in the swap idle bit. Minchan, can
you provide more thoughts here? (He is on 2-week vacation from today so
hopefully replies before he vanishes ;-)).
We can move on with the rest of the series in the mean time but I would
like to see a proper justification for the swap entries and why they
should be handled special.
Ok, I will improve the changelog.
quoted
Also assuming all swap pages as idle has other "semantic" issues. It is quite
odd if a swapped page is automatically marked as idle without userspace
telling it to. Consider the following set of events: 1. Userspace marks only
a certain memory region as idle. 2. Userspace reads back the bits
corresponding to a bigger region. Part of this bigger region is swapped.
Userspace expects all of the pages it did not mark, to have idle bit set to
'0' because it never marked them as idle. However if it is now surprised by
what it read back (not all '0' read back). Since a page is swapped, it will
be now marked "automatically" as idle as per your proposal, even if userspace
never marked it explicity before. This would be quite confusing/ambiguous.
OK, I see. I guess the primary question I have is how do you distinguish
Idle page which got unmapped and faulted in again from swapped out page
and refaulted - including the time the pte is not present.
From: Joel Fernandes <hidden> Date: 2019-08-06 13:49:01
On Tue, Aug 06, 2019 at 01:44:02PM +0200, Michal Hocko wrote:
[snip]
quoted
quoted
quoted
This operation even if expensive is only done once during the access of the
page_idle file. Did you have a better fix in mind?
Can we set the idle bit also for non-lru pages as long as they are
reachable via pte?
Not at the moment with the current page idle tracking code. PageLRU(page)
flag is checked in page_idle_get_page().
yes, I am aware of the current code. I strongly suspect that the PageLRU
check was there to not mark arbitrary page looked up by pfn with the
idle bit because that would be unexpected. But I might be easily wrong
here.
Yes, quite possible.
quoted
Even if we could set it for non-LRU, the idle bit (page flag) would not be
cleared if page is not on LRU because page-reclaim code (page_referenced() I
believe) would not clear it.
Yes, it is either reclaim when checking references as you say but also
mark_page_accessed. I believe the later might still have the page on the
pcp LRU add cache. Maybe I am missing something something but it seems
that there is nothing fundamentally requiring the user mapped page to be
on the LRU list when seting the idle bit.
That being said, your big hammer approach will work more reliable but if
you do not feel like changing the underlying PageLRU assumption then
document that draining should be removed longterm.
Yes, at the moment I am in preference of keeping the underlying assumption
same. I am Ok with adding of a comment on the drain call that it is to be
removed longterm.
thanks,
- Joel
From: Michal Hocko <mhocko@kernel.org> Date: 2019-08-06 14:10:10
On Tue 06-08-19 09:43:21, Joel Fernandes wrote:
On Tue, Aug 06, 2019 at 01:57:03PM +0200, Michal Hocko wrote:
quoted
On Tue 06-08-19 07:14:46, Joel Fernandes wrote:
quoted
On Tue, Aug 06, 2019 at 12:47:55PM +0200, Michal Hocko wrote:
quoted
On Tue 06-08-19 06:36:27, Joel Fernandes wrote:
quoted
On Tue, Aug 06, 2019 at 10:42:03AM +0200, Michal Hocko wrote:
quoted
On Mon 05-08-19 13:04:49, Joel Fernandes (Google) wrote:
quoted
This bit will be used by idle page tracking code to correctly identify
if a page that was swapped out was idle before it got swapped out.
Without this PTE bit, we lose information about if a page is idle or not
since the page frame gets unmapped.
And why do we need that? Why cannot we simply assume all swapped out
pages to be idle? They were certainly idle enough to be reclaimed,
right? Or what does idle actualy mean here?
Yes, but other than swapping, in Android a page can be forced to be swapped
out as well using the new hints that Minchan is adding?
Yes and that is effectivelly making them idle, no?
That depends on how you think of it.
I would much prefer to have it documented so that I do not have to guess ;)
Sure :)
quoted
quoted
If you are thinking of a monitoring
process like a heap profiler, then from the heap profiler's (that only cares
about the process it is monitoring) perspective it will look extremely odd if
pages that are recently accessed by the process appear to be idle which would
falsely look like those processes are leaking memory. The reality being,
Android forced those pages into swap because of other reasons. I would like
for the swapping mechanism, whether forced swapping or memory reclaim, not to
interfere with the idle detection.
Hmm, but how are you going to handle situation when the page is unmapped
and refaulted again (e.g. a normal reclaim of a pagecache)? You are
losing that information same was as in the swapout case, no? Or am I
missing something?
Yes you are right, it would have the same issue, thanks for bringing it up.
Should we rename this bit to PTE_IDLE and do the same thing that we are doing
for swap?
What if we decide to tear the page table down as well? E.g. because we
can reclaim file backed mappings and free some memory used for page
tables. We do not do that right now but I can see that really large
mappings might push us that direction. Sure this is mostly a theoretical
concern but I am wondering whether promissing to keep the idle bit over
unmapping is not too much.
I am not sure how to deal with this myself, TBH. In any case the current
semantic - via pfn - will lose the idle bit already so can we mimic it
as well? We only have 1 bit for each address which makes it challenging.
The easiest way would be to declare that the idle bit might disappear on
activating or reclaiming the page. How well that suits different
usecases is a different question. I would be interested in hearing from
other people about this of course.
--
Michal Hocko
SUSE Labs
From: Minchan Kim <minchan@kernel.org> Date: 2019-08-06 14:48:07
On Tue, Aug 06, 2019 at 01:57:03PM +0200, Michal Hocko wrote:
On Tue 06-08-19 07:14:46, Joel Fernandes wrote:
quoted
On Tue, Aug 06, 2019 at 12:47:55PM +0200, Michal Hocko wrote:
quoted
On Tue 06-08-19 06:36:27, Joel Fernandes wrote:
quoted
On Tue, Aug 06, 2019 at 10:42:03AM +0200, Michal Hocko wrote:
quoted
On Mon 05-08-19 13:04:49, Joel Fernandes (Google) wrote:
quoted
This bit will be used by idle page tracking code to correctly identify
if a page that was swapped out was idle before it got swapped out.
Without this PTE bit, we lose information about if a page is idle or not
since the page frame gets unmapped.
And why do we need that? Why cannot we simply assume all swapped out
pages to be idle? They were certainly idle enough to be reclaimed,
right? Or what does idle actualy mean here?
Yes, but other than swapping, in Android a page can be forced to be swapped
out as well using the new hints that Minchan is adding?
Yes and that is effectivelly making them idle, no?
That depends on how you think of it.
I would much prefer to have it documented so that I do not have to guess ;)
quoted
If you are thinking of a monitoring
process like a heap profiler, then from the heap profiler's (that only cares
about the process it is monitoring) perspective it will look extremely odd if
pages that are recently accessed by the process appear to be idle which would
falsely look like those processes are leaking memory. The reality being,
Android forced those pages into swap because of other reasons. I would like
for the swapping mechanism, whether forced swapping or memory reclaim, not to
interfere with the idle detection.
Hmm, but how are you going to handle situation when the page is unmapped
and refaulted again (e.g. a normal reclaim of a pagecache)? You are
losing that information same was as in the swapout case, no? Or am I
missing something?
If page is unmapped, it's not a idle memory any longer because it's
free memory. We could detect the pte is not present.
If page is refaulted, it's not a idle memory any longer because it's
accessed again. We could detect it because the newly allocated page
doesn't have a PG_idle page flag.
Both case, idle page tracking couldn't report them as IDLE so it's okay.
From: Joel Fernandes <hidden> Date: 2019-08-06 15:20:15
On Tue, Aug 06, 2019 at 11:47:47PM +0900, Minchan Kim wrote:
On Tue, Aug 06, 2019 at 01:57:03PM +0200, Michal Hocko wrote:
quoted
On Tue 06-08-19 07:14:46, Joel Fernandes wrote:
quoted
On Tue, Aug 06, 2019 at 12:47:55PM +0200, Michal Hocko wrote:
quoted
On Tue 06-08-19 06:36:27, Joel Fernandes wrote:
quoted
On Tue, Aug 06, 2019 at 10:42:03AM +0200, Michal Hocko wrote:
quoted
On Mon 05-08-19 13:04:49, Joel Fernandes (Google) wrote:
quoted
This bit will be used by idle page tracking code to correctly identify
if a page that was swapped out was idle before it got swapped out.
Without this PTE bit, we lose information about if a page is idle or not
since the page frame gets unmapped.
And why do we need that? Why cannot we simply assume all swapped out
pages to be idle? They were certainly idle enough to be reclaimed,
right? Or what does idle actualy mean here?
Yes, but other than swapping, in Android a page can be forced to be swapped
out as well using the new hints that Minchan is adding?
Yes and that is effectivelly making them idle, no?
That depends on how you think of it.
I would much prefer to have it documented so that I do not have to guess ;)
quoted
If you are thinking of a monitoring
process like a heap profiler, then from the heap profiler's (that only cares
about the process it is monitoring) perspective it will look extremely odd if
pages that are recently accessed by the process appear to be idle which would
falsely look like those processes are leaking memory. The reality being,
Android forced those pages into swap because of other reasons. I would like
for the swapping mechanism, whether forced swapping or memory reclaim, not to
interfere with the idle detection.
Hmm, but how are you going to handle situation when the page is unmapped
and refaulted again (e.g. a normal reclaim of a pagecache)? You are
losing that information same was as in the swapout case, no? Or am I
missing something?
If page is unmapped, it's not a idle memory any longer because it's
free memory. We could detect the pte is not present.
I think Michal is not talking of explictly being unmapped, but about the case
where a file-backed mapped page is unmapped due to memory pressure ? This is
similar to the swap situation.
Basically... file page is marked idle, then it is accessed by userspace. Then
memory pressure drops it off the page cache so the idle information is lost.
Next time we check the page_idle, we miss that it was accessed indeed.
It is not an issue for the heap profiler or anonymous memory per-se. But is
similar to the swap situation.
If page is refaulted, it's not a idle memory any longer because it's
accessed again. We could detect it because the newly allocated page
doesn't have a PG_idle page flag.
In the refault case, yes it should not be a problem.
thanks,
- Joel
From: Andrew Morton <akpm@linux-foundation.org> Date: 2019-08-06 22:19:28
(cc Brendan's other email address, hoping for review input ;))
On Mon, 5 Aug 2019 13:04:47 -0400 "Joel Fernandes (Google)" [off-list ref] wrote:
The page_idle tracking feature currently requires looking up the pagemap
for a process followed by interacting with /sys/kernel/mm/page_idle.
Looking up PFN from pagemap in Android devices is not supported by
unprivileged process and requires SYS_ADMIN and gives 0 for the PFN.
This patch adds support to directly interact with page_idle tracking at
the PID level by introducing a /proc/<pid>/page_idle file. It follows
the exact same semantics as the global /sys/kernel/mm/page_idle, but now
looking up PFN through pagemap is not needed since the interface uses
virtual frame numbers, and at the same time also does not require
SYS_ADMIN.
In Android, we are using this for the heap profiler (heapprofd) which
profiles and pin points code paths which allocates and leaves memory
idle for long periods of time. This method solves the security issue
with userspace learning the PFN, and while at it is also shown to yield
better results than the pagemap lookup, the theory being that the window
where the address space can change is reduced by eliminating the
intermediate pagemap look up stage. In virtual address indexing, the
process's mmap_sem is held for the duration of the access.
Quite a lot of changes to the page_idle code. Has this all been
runtime tested on architectures where
CONFIG_HAVE_ARCH_PTE_SWP_PGIDLE=n? That could be x86 with a little
Kconfig fiddle-for-testing-purposes.
From: Joel Fernandes <hidden> Date: 2019-08-07 10:00:20
On Tue, Aug 06, 2019 at 03:19:21PM -0700, Andrew Morton wrote:
(cc Brendan's other email address, hoping for review input ;))
;)
On Mon, 5 Aug 2019 13:04:47 -0400 "Joel Fernandes (Google)" [off-list ref] wrote:
quoted
The page_idle tracking feature currently requires looking up the pagemap
for a process followed by interacting with /sys/kernel/mm/page_idle.
Looking up PFN from pagemap in Android devices is not supported by
unprivileged process and requires SYS_ADMIN and gives 0 for the PFN.
This patch adds support to directly interact with page_idle tracking at
the PID level by introducing a /proc/<pid>/page_idle file. It follows
the exact same semantics as the global /sys/kernel/mm/page_idle, but now
looking up PFN through pagemap is not needed since the interface uses
virtual frame numbers, and at the same time also does not require
SYS_ADMIN.
In Android, we are using this for the heap profiler (heapprofd) which
profiles and pin points code paths which allocates and leaves memory
idle for long periods of time. This method solves the security issue
with userspace learning the PFN, and while at it is also shown to yield
better results than the pagemap lookup, the theory being that the window
where the address space can change is reduced by eliminating the
intermediate pagemap look up stage. In virtual address indexing, the
process's mmap_sem is held for the duration of the access.
Quite a lot of changes to the page_idle code. Has this all been
runtime tested on architectures where
CONFIG_HAVE_ARCH_PTE_SWP_PGIDLE=n? That could be x86 with a little
Kconfig fiddle-for-testing-purposes.
I will do this Kconfig fiddle test with CONFIG_HAVE_ARCH_PTE_SWP_PGIDLE=n and test
the patch as well.
In previous series, this flag was not there (which should have been
equivalent to the above test), and things are working fine.
Quite a lot of new code unconditionally added to major architectures.
Are we confident that everyone will want this feature?
I did not follow, could you clarify more? All of this diff stat is not to
architecture code:
arch/Kconfig | 3 ++
fs/proc/base.c | 3 ++
fs/proc/internal.h | 1 +
fs/proc/task_mmu.c | 43 +++++++++++++++++++++
include/asm-generic/pgtable.h | 6 +++
include/linux/page_idle.h | 4 ++
mm/page_idle.c | 359 +++++++++++++++++++++++++++++..
mm/rmap.c | 2 +
8 files changed, 376 insertions(+), 45 deletions(-)
The arcitecture change is in a later patch, and is not that many lines.
Also, I am planning to split the swap functionality of the patch into a
separate one for easier review.
Quite a lot of new code unconditionally added to major architectures.
Are we confident that everyone will want this feature?
I did not follow, could you clarify more? All of this diff stat is not to
architecture code:
My point is that the patchset adds a lot of new code with no way in
which users can opt out. Almost everyone gets a fatter kernel - how
many of those users will actually benefit from it?
If "not many" then shouldn't we be making it Kconfigurable?
Are there userspace tools which present this info to users or which
provide monitoring of some form? Do major distros ship those tools?
Do people use them? etcetera.
Quite a lot of new code unconditionally added to major architectures.
Are we confident that everyone will want this feature?
I did not follow, could you clarify more? All of this diff stat is not to
architecture code:
My point is that the patchset adds a lot of new code with no way in
which users can opt out. Almost everyone gets a fatter kernel - how
many of those users will actually benefit from it?
If "not many" then shouldn't we be making it Kconfigurable?
Almost all of this code is already configurable with
CONFIG_IDLE_PAGE_TRACKING. If you disable it, then all of this code gets
disabled.
Or are you referring to something else that needs to be made configurable?
Are there userspace tools which present this info to users or which
provide monitoring of some form? Do major distros ship those tools?
Do people use them? etcetera.
Android's heapprofd is what I was working on which is already using it (patch
is not yet upstreamed). There is working set tracking which Sandeep (also
from Android) said he wants to use. Minchan plans to use this in combination
with ZRAM-based idle tracking. Mike Rappoport also showed some interest, but
I am not sure where/how he is using it. These are just some of the usecases I
am aware off. I am pretty sure more will come as well.
thanks,
- Joel