From: Vladimir Davydov <hidden> Date: 2015-07-19 12:31:40
Hi,
This patch set introduces a new user API for tracking user memory pages
that have not been used for a given period of time. The purpose of this
is to provide the userspace with the means of tracking a workload's
working set, i.e. the set of pages that are actively used by the
workload. Knowing the working set size can be useful for partitioning
the system more efficiently, e.g. by tuning memory cgroup limits
appropriately, or for job placement within a compute cluster.
It is based on top of v4.2-rc2-mmotm-2015-07-15-16-46
It applies without conflicts to v4.2-rc2-mmotm-2015-07-17-16-04 as well
---- USE CASES ----
The unified cgroup hierarchy has memory.low and memory.high knobs, which
are defined as the low and high boundaries for the workload working set
size. However, the working set size of a workload may be unknown or
change in time. With this patch set, one can periodically estimate the
amount of memory unused by each cgroup and tune their memory.low and
memory.high parameters accordingly, therefore optimizing the overall
memory utilization.
Another use case is balancing workloads within a compute cluster.
Knowing how much memory is not really used by a workload unit may help
take a more optimal decision when considering migrating the unit to
another node within the cluster.
Also, as noted by Minchan, this would be useful for per-process reclaim
(https://lwn.net/Articles/545668/). With idle tracking, we could reclaim idle
pages only by smart user memory manager.
---- USER API ----
The user API consists of two new proc files:
* /proc/kpageidle. This file implements a bitmap where each bit corresponds
to a page, indexed by PFN. When the bit is set, the corresponding page is
idle. A page is considered idle if it has not been accessed since it was
marked idle. To mark a page idle one should set the bit corresponding to the
page by writing to the file. A value written to the file is OR-ed with the
current bitmap value. Only user memory pages can be marked idle, for other
page types input is silently ignored. Writing to this file beyond max PFN
results in the ENXIO error. Only available when CONFIG_IDLE_PAGE_TRACKING is
set.
This file can be used to estimate the amount of pages that are not
used by a particular workload as follows:
1. mark all pages of interest idle by setting corresponding bits in the
/proc/kpageidle bitmap
2. wait until the workload accesses its working set
3. read /proc/kpageidle and count the number of bits set
* /proc/kpagecgroup. This file contains a 64-bit inode number of the
memory cgroup each page is charged to, indexed by PFN. Only available when
CONFIG_MEMCG is set.
This file can be used to find all pages (including unmapped file
pages) accounted to a particular cgroup. Using /proc/kpageidle, one
can then estimate the cgroup working set size.
For an example of using these files for estimating the amount of unused
memory pages per each memory cgroup, please see the script attached
below.
---- REASONING ----
The reason to introduce the new user API instead of using
/proc/PID/{clear_refs,smaps} is that the latter has two serious
drawbacks:
- it does not count unmapped file pages
- it affects the reclaimer logic
The new API attempts to overcome them both. For more details on how it
is achieved, please see the comment to patch 6.
---- CHANGE LOG ----
Changes in v9:
- add cond_resched to /proc/kpage* read/write loop (Andres)
- rebase on top of v4.2-rc2-mmotm-2015-07-15-16-46
Changes in v8:
- clear referenced/accessed bit in secondary ptes while accessing
/proc/kpageidle; this is required to estimate wss of KVM VMs (Andres)
- check the young flag when collapsing a huge page
- copy idle/young flags on page migration
Changes in v7:
This iteration addresses Andres's comments to v6:
- do not reuse page_referenced for clearing idle flag, introduce a
separate function instead; this way we won't issue expensive tlb
flushes on /proc/kpageidle read/write
- propagate young/idle flags from head to tail pages on thp split
- skip compound tail pages while reading/writing /proc/kpageidle
- cleanup page_referenced_one
Changes in v6:
- Split the patch introducing page_cgroup_ino helper to ease review.
- Rebase on top of v4.1-rc7-mmotm-2015-06-09-16-55
Changes in v5:
- Fix possible race between kpageidle_clear_pte_refs() and
__page_set_anon_rmap() by checking that a page is on an LRU list
under zone->lru_lock (Minchan).
- Export idle flag via /proc/kpageflags (Minchan).
- Rebase on top of 4.1-rc3.
Changes in v4:
This iteration primarily addresses Minchan's comments to v3:
- Implement /proc/kpageidle as a bitmap instead of using u64 per each page,
because there does not seem to be any future uses for the other 63 bits.
- Do not double-increase pra->referenced in page_referenced_one() if the page
was young and referenced recently.
- Remove the pointless (page_count == 0) check from kpageidle_get_page().
- Rename kpageidle_clear_refs() to kpageidle_clear_pte_refs().
- Improve comments to kpageidle-related functions.
- Rebase on top of 4.1-rc2.
Note it does not address Minchan's concern of possible __page_set_anon_rmap vs
page_referenced race (see https://lkml.org/lkml/2015/5/3/220) since it is still
unclear if this race can really happen (see https://lkml.org/lkml/2015/5/4/160)
Changes in v3:
- Enable CONFIG_IDLE_PAGE_TRACKING for 32 bit. Since this feature
requires two extra page flags and there is no space for them on 32
bit, page ext is used (thanks to Minchan Kim).
- Minor code cleanups and comments improved.
- Rebase on top of 4.1-rc1.
Changes in v2:
- The main difference from v1 is the API change. In v1 the user can
only set the idle flag for all pages at once, and for clearing the
Idle flag on pages accessed via page tables /proc/PID/clear_refs
should be used.
The main drawback of the v1 approach, as noted by Minchan, is that on
big machines setting the idle flag for each pages can result in CPU
bursts, which would be especially frustrating if the user only wanted
to estimate the amount of idle pages for a particular process or VMA.
With the new API a more fine-grained approach is possible: one can
read a process's /proc/PID/pagemap and set/check the Idle flag only
for those pages of the process's address space he or she is
interested in.
Another good point about the v2 API is that it is possible to limit
/proc/kpage* scanning rate when the user wants to estimate the total
number of idle pages, which is unachievable with the v1 approach.
- Make /proc/kpagecgroup return the ino of the closest online ancestor
in case the cgroup a page is charged to is offline.
- Fix /proc/PID/clear_refs not clearing Young page flag.
- Rebase on top of v4.0-rc6-mmotm-2015-04-01-14-54
v8: https://lkml.org/lkml/2015/7/15/587
v7: https://lkml.org/lkml/2015/7/11/119
v6: https://lkml.org/lkml/2015/6/12/301
v5: https://lkml.org/lkml/2015/5/12/449
v4: https://lkml.org/lkml/2015/5/7/580
v3: https://lkml.org/lkml/2015/4/28/224
v2: https://lkml.org/lkml/2015/4/7/260
v1: https://lkml.org/lkml/2015/3/18/794
---- PATCH SET STRUCTURE ----
The patch set is organized as follows:
- patch 1 adds page_cgroup_ino() helper for the sake of
/proc/kpagecgroup and patches 2-3 do related cleanup
- patch 4 adds /proc/kpagecgroup, which reports cgroup ino each page is
charged to
- patch 5 introduces a new mmu notifier callback, clear_young, which is
a lightweight version of clear_flush_young; it is used in patch 6
- patch 6 implements the idle page tracking feature, including the
userspace API, /proc/kpageidle
- patch 7 exports idle flag via /proc/kpageflags
---- SIMILAR WORKS ----
Originally, the patch for tracking idle memory was proposed back in 2011
by Michel Lespinasse (see http://lwn.net/Articles/459269/). The main
difference between Michel's patch and this one is that Michel
implemented a kernel space daemon for estimating idle memory size per
cgroup while this patch only provides the userspace with the minimal API
for doing the job, leaving the rest up to the userspace. However, they
both share the same idea of Idle/Young page flags to avoid affecting the
reclaimer logic.
---- PERFORMANCE EVALUATION ----
SPECjvm2008 (https://www.spec.org/jvm2008/) was used to evaluate the
performance impact introduced by this patch set. Three runs were carried
out:
- base: kernel without the patch
- patched: patched kernel, the feature is not used
- patched-active: patched kernel, 1 minute-period daemon is used for
tracking idle memory
For tracking idle memory, idlememstat utility was used:
https://github.com/locker/idlememstat
testcase base patched patched-active
compiler 537.40 ( 0.00)% 532.26 (-0.96)% 538.31 ( 0.17)%
compress 305.47 ( 0.00)% 301.08 (-1.44)% 300.71 (-1.56)%
crypto 284.32 ( 0.00)% 282.21 (-0.74)% 284.87 ( 0.19)%
derby 411.05 ( 0.00)% 413.44 ( 0.58)% 412.07 ( 0.25)%
mpegaudio 189.96 ( 0.00)% 190.87 ( 0.48)% 189.42 (-0.28)%
scimark.large 46.85 ( 0.00)% 46.41 (-0.94)% 47.83 ( 2.09)%
scimark.small 412.91 ( 0.00)% 415.41 ( 0.61)% 421.17 ( 2.00)%
serial 204.23 ( 0.00)% 213.46 ( 4.52)% 203.17 (-0.52)%
startup 36.76 ( 0.00)% 35.49 (-3.45)% 35.64 (-3.05)%
sunflow 115.34 ( 0.00)% 115.08 (-0.23)% 117.37 ( 1.76)%
xml 620.55 ( 0.00)% 619.95 (-0.10)% 620.39 (-0.03)%
composite 211.50 ( 0.00)% 211.15 (-0.17)% 211.67 ( 0.08)%
time idlememstat:
17.20user 65.16system 2:15:23elapsed 1%CPU (0avgtext+0avgdata 8476maxresident)k
448inputs+40outputs (1major+36052minor)pagefaults 0swaps
---- SCRIPT FOR COUNTING IDLE PAGES PER CGROUP ----
#! /usr/bin/python
#
import os
import stat
import errno
import struct
CGROUP_MOUNT = "/sys/fs/cgroup/memory"
BUFSIZE = 8 * 1024 # must be multiple of 8
def get_hugepage_size():
with open("/proc/meminfo", "r") as f:
for s in f:
k, v = s.split(":")
if k == "Hugepagesize":
return int(v.split()[0]) * 1024
PAGE_SIZE = os.sysconf("SC_PAGE_SIZE")
HUGEPAGE_SIZE = get_hugepage_size()
def set_idle():
f = open("/proc/kpageidle", "wb", BUFSIZE)
while True:
try:
f.write(struct.pack("Q", pow(2, 64) - 1))
except IOError as err:
if err.errno == errno.ENXIO:
break
raise
f.close()
def count_idle():
f_flags = open("/proc/kpageflags", "rb", BUFSIZE)
f_cgroup = open("/proc/kpagecgroup", "rb", BUFSIZE)
with open("/proc/kpageidle", "rb", BUFSIZE) as f:
while f.read(BUFSIZE): pass # update idle flag
idlememsz = {}
while True:
s1, s2 = f_flags.read(8), f_cgroup.read(8)
if not s1 or not s2:
break
flags, = struct.unpack('Q', s1)
cgino, = struct.unpack('Q', s2)
unevictable = (flags >> 18) & 1
huge = (flags >> 22) & 1
idle = (flags >> 25) & 1
if idle and not unevictable:
idlememsz[cgino] = idlememsz.get(cgino, 0) + \
(HUGEPAGE_SIZE if huge else PAGE_SIZE)
f_flags.close()
f_cgroup.close()
return idlememsz
if __name__ == "__main__":
print "Setting the idle flag for each page..."
set_idle()
raw_input("Wait until the workload accesses its working set, "
"then press Enter")
print "Counting idle pages..."
idlememsz = count_idle()
for dir, subdirs, files in os.walk(CGROUP_MOUNT):
ino = os.stat(dir)[stat.ST_INO]
print dir + ": " + str(idlememsz.get(ino, 0) / 1024) + " kB"
---- END SCRIPT ----
Comments are more than welcome.
Thanks,
Vladimir Davydov (8):
memcg: add page_cgroup_ino helper
hwpoison: use page_cgroup_ino for filtering by memcg
memcg: zap try_get_mem_cgroup_from_page
proc: add kpagecgroup file
mmu-notifier: add clear_young callback
proc: add kpageidle file
proc: export idle flag via kpageflags
proc: add cond_resched to /proc/kpage* read/write loop
Documentation/vm/pagemap.txt | 22 ++-
fs/proc/page.c | 282 +++++++++++++++++++++++++++++++++
fs/proc/task_mmu.c | 4 +-
include/linux/memcontrol.h | 10 +-
include/linux/mm.h | 98 ++++++++++++
include/linux/mmu_notifier.h | 44 +++++
include/linux/page-flags.h | 11 ++
include/linux/page_ext.h | 4 +
include/uapi/linux/kernel-page-flags.h | 1 +
mm/Kconfig | 12 ++
mm/debug.c | 4 +
mm/huge_memory.c | 11 +-
mm/hwpoison-inject.c | 5 +-
mm/memcontrol.c | 71 ++++-----
mm/memory-failure.c | 16 +-
mm/migrate.c | 5 +
mm/mmu_notifier.c | 17 ++
mm/page_ext.c | 3 +
mm/rmap.c | 5 +
mm/swap.c | 2 +
virt/kvm/kvm_main.c | 18 +++
21 files changed, 579 insertions(+), 66 deletions(-)
--
2.1.4
From: Vladimir Davydov <hidden> Date: 2015-07-19 12:31:47
This function returns the inode number of the closest online ancestor of
the memory cgroup a page is charged to. It is required for exporting
information about which page is charged to which cgroup to userspace,
which will be introduced by a following patch.
Signed-off-by: Vladimir Davydov <redacted>
Reviewed-by: Andres Lagar-Cavilla <redacted>
---
include/linux/memcontrol.h | 1 +
mm/memcontrol.c | 23 +++++++++++++++++++++++
2 files changed, 24 insertions(+)
--
2.1.4
--
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>
From: Vladimir Davydov <hidden> Date: 2015-07-19 12:31:54
Hwpoison allows to filter pages by memory cgroup ino. Currently, it
calls try_get_mem_cgroup_from_page to obtain the cgroup from a page and
then its ino using cgroup_ino, but now we have an apter method for that,
page_cgroup_ino, so use it instead.
Signed-off-by: Vladimir Davydov <redacted>
Reviewed-by: Andres Lagar-Cavilla <redacted>
---
mm/hwpoison-inject.c | 5 +----
mm/memory-failure.c | 16 ++--------------
2 files changed, 3 insertions(+), 18 deletions(-)
--
2.1.4
--
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>
From: Vladimir Davydov <hidden> Date: 2015-07-19 12:32:05
It is only used in mem_cgroup_try_charge, so fold it in and zap it.
Signed-off-by: Vladimir Davydov <redacted>
---
include/linux/memcontrol.h | 9 +--------
mm/memcontrol.c | 48 ++++++++++++----------------------------------
2 files changed, 13 insertions(+), 44 deletions(-)
--
2.1.4
--
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>
From: Vladimir Davydov <hidden> Date: 2015-07-19 12:32:14
/proc/kpagecgroup contains a 64-bit inode number of the memory cgroup
each page is charged to, indexed by PFN. Having this information is
useful for estimating a cgroup working set size.
The file is present if CONFIG_PROC_PAGE_MONITOR && CONFIG_MEMCG.
Signed-off-by: Vladimir Davydov <redacted>
---
Documentation/vm/pagemap.txt | 6 ++++-
fs/proc/page.c | 53 ++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 58 insertions(+), 1 deletion(-)
@@ -5,7 +5,7 @@ pagemap is a new (as of 2.6.25) set of interfaces in the kernel that allow userspace programs to examine the page tables and related information by reading files in /proc.-There are three components to pagemap:+There are four components to pagemap: * /proc/pid/pagemap. This file lets a userspace process find out which physical frame each virtual page is mapped to. It contains one 64-bit
@@ -66,6 +66,10 @@ There are three components to pagemap: 23. BALLOON 24. ZERO_PAGE+ * /proc/kpagecgroup. This file contains a 64-bit inode number of the+ memory cgroup each page is charged to, indexed by PFN. Only available when+ CONFIG_MEMCG is set.+ Short descriptions to the page flags: 0. LOCKED
--
2.1.4
--
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>
From: Vladimir Davydov <hidden> Date: 2015-07-19 12:32:23
In the scope of the idle memory tracking feature, which is introduced by
the following patch, we need to clear the referenced/accessed bit not
only in primary, but also in secondary ptes. The latter is required in
order to estimate wss of KVM VMs. At the same time we want to avoid
flushing tlb, because it is quite expensive and it won't really affect
the final result.
Currently, there is no function for clearing pte young bit that would
meet our requirements, so this patch introduces one. To achieve that we
have to add a new mmu-notifier callback, clear_young, since there is no
method for testing-and-clearing a secondary pte w/o flushing tlb. The
new method is not mandatory and currently only implemented by KVM.
Signed-off-by: Vladimir Davydov <redacted>
Reviewed-by: Andres Lagar-Cavilla <redacted>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
---
include/linux/mmu_notifier.h | 44 ++++++++++++++++++++++++++++++++++++++++++++
mm/mmu_notifier.c | 17 +++++++++++++++++
virt/kvm/kvm_main.c | 18 ++++++++++++++++++
3 files changed, 79 insertions(+)
--
2.1.4
--
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>
From: Vladimir Davydov <hidden> Date: 2015-07-19 12:32:34
Knowing the portion of memory that is not used by a certain application
or memory cgroup (idle memory) can be useful for partitioning the system
efficiently, e.g. by setting memory cgroup limits appropriately.
Currently, the only means to estimate the amount of idle memory provided
by the kernel is /proc/PID/{clear_refs,smaps}: the user can clear the
access bit for all pages mapped to a particular process by writing 1 to
clear_refs, wait for some time, and then count smaps:Referenced.
However, this method has two serious shortcomings:
- it does not count unmapped file pages
- it affects the reclaimer logic
To overcome these drawbacks, this patch introduces two new page flags,
Idle and Young, and a new proc file, /proc/kpageidle. A page's Idle flag
can only be set from userspace by setting bit in /proc/kpageidle at the
offset corresponding to the page, and it is cleared whenever the page is
accessed either through page tables (it is cleared in page_referenced()
in this case) or using the read(2) system call (mark_page_accessed()).
Thus by setting the Idle flag for pages of a particular workload, which
can be found e.g. by reading /proc/PID/pagemap, waiting for some time to
let the workload access its working set, and then reading the kpageidle
file, one can estimate the amount of pages that are not used by the
workload.
The Young page flag is used to avoid interference with the memory
reclaimer. A page's Young flag is set whenever the Access bit of a page
table entry pointing to the page is cleared by writing to kpageidle. If
page_referenced() is called on a Young page, it will add 1 to its return
value, therefore concealing the fact that the Access bit was cleared.
Note, since there is no room for extra page flags on 32 bit, this
feature uses extended page flags when compiled on 32 bit.
Signed-off-by: Vladimir Davydov <redacted>
---
Documentation/vm/pagemap.txt | 12 ++-
fs/proc/page.c | 218 +++++++++++++++++++++++++++++++++++++++++++
fs/proc/task_mmu.c | 4 +-
include/linux/mm.h | 98 +++++++++++++++++++
include/linux/page-flags.h | 11 +++
include/linux/page_ext.h | 4 +
mm/Kconfig | 12 +++
mm/debug.c | 4 +
mm/huge_memory.c | 11 ++-
mm/migrate.c | 5 +
mm/page_ext.c | 3 +
mm/rmap.c | 5 +
mm/swap.c | 2 +
13 files changed, 385 insertions(+), 4 deletions(-)
@@ -5,7 +5,7 @@ pagemap is a new (as of 2.6.25) set of interfaces in the kernel that allow userspace programs to examine the page tables and related information by reading files in /proc.-There are four components to pagemap:+There are five components to pagemap: * /proc/pid/pagemap. This file lets a userspace process find out which physical frame each virtual page is mapped to. It contains one 64-bit
@@ -70,6 +70,16 @@ There are four components to pagemap: memory cgroup each page is charged to, indexed by PFN. Only available when CONFIG_MEMCG is set.+ * /proc/kpageidle. This file implements a bitmap where each bit corresponds+ to a page, indexed by PFN. When the bit is set, the corresponding page is+ idle. A page is considered idle if it has not been accessed since it was+ marked idle. To mark a page idle one should set the bit corresponding to the+ page by writing to the file. A value written to the file is OR-ed with the+ current bitmap value. Only user memory pages can be marked idle, for other+ page types input is silently ignored. Writing to this file beyond max PFN+ results in the ENXIO error. Only available when CONFIG_IDLE_PAGE_TRACKING is+ set.+ Short descriptions to the page flags: 0. LOCKED
@@ -459,7 +459,7 @@ static void smaps_account(struct mem_size_stats *mss, struct page *page,mss->resident+=size;/* Accumulate the size in pages that have been accessed. */-if(young||PageReferenced(page))+if(young||page_is_young(page)||PageReferenced(page))mss->referenced+=size;mapcount=page_mapcount(page);if(mapcount>=2){
@@ -808,6 +808,7 @@ static int clear_refs_pte_range(pmd_t *pmd, unsigned long addr,/* Clear accessed and referenced bits. */pmdp_test_and_clear_young(vma,addr,pmd);+test_and_clear_page_young(page);ClearPageReferenced(page);out:spin_unlock(ptl);
@@ -2311,7 +2316,8 @@ static int __collapse_huge_page_isolate(struct vm_area_struct *vma,VM_BUG_ON_PAGE(PageLRU(page),page);/* If there is no mapped pte young don't collapse the page */-if(pte_young(pteval)||PageReferenced(page)||+if(pte_young(pteval)||+page_is_young(page)||PageReferenced(page)||mmu_notifier_test_young(vma->vm_mm,address))referenced=true;}
@@ -2738,7 +2744,8 @@ static int khugepaged_scan_pmd(struct mm_struct *mm,*/if(page_count(page)!=1+!!PageSwapCache(page))gotoout_unmap;-if(pte_young(pteval)||PageReferenced(page)||+if(pte_young(pteval)||+page_is_young(page)||PageReferenced(page)||mmu_notifier_test_young(vma->vm_mm,address))referenced=true;}
--
2.1.4
--
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>
From: Vladimir Davydov <hidden> Date: 2015-07-19 12:32:43
As noted by Minchan, a benefit of reading idle flag from
/proc/kpageflags is that one can easily filter dirty and/or unevictable
pages while estimating the size of unused memory.
Note that idle flag read from /proc/kpageflags may be stale in case the
page was accessed via a PTE, because it would be too costly to iterate
over all page mappings on each /proc/kpageflags read to provide an
up-to-date value. To make sure the flag is up-to-date one has to read
/proc/kpageidle first.
Signed-off-by: Vladimir Davydov <redacted>
Reviewed-by: Andres Lagar-Cavilla <redacted>
---
Documentation/vm/pagemap.txt | 6 ++++++
fs/proc/page.c | 3 +++
include/uapi/linux/kernel-page-flags.h | 1 +
3 files changed, 10 insertions(+)
@@ -65,6 +65,7 @@ There are five components to pagemap: 22. THP 23. BALLOON 24. ZERO_PAGE+ 25. IDLE * /proc/kpagecgroup. This file contains a 64-bit inode number of the memory cgroup each page is charged to, indexed by PFN. Only available when
@@ -125,6 +126,11 @@ Short descriptions to the page flags: 24. ZERO_PAGE zero page for pfn_zero or huge_zero page+25. IDLE+ page has not been accessed since it was marked idle (see /proc/kpageidle)+ Note that this flag may be stale in case the page was accessed via a PTE.+ To make sure the flag is up-to-date one has to read /proc/kpageidle first.+ [IO related page flags] 1. ERROR IO error occurred 3. UPTODATE page has up-to-date data
--
2.1.4
--
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>
From: Vladimir Davydov <hidden> Date: 2015-07-19 12:32:52
Reading/writing a /proc/kpage* file may take long on machines with a lot
of RAM installed.
Suggested-by: Andres Lagar-Cavilla <redacted>
Signed-off-by: Vladimir Davydov <redacted>
---
fs/proc/page.c | 8 ++++++++
1 file changed, 8 insertions(+)
--
2.1.4
--
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>
From: Andres Lagar-Cavilla <hidden> Date: 2015-07-20 18:34:22
On Sun, Jul 19, 2015 at 5:31 AM, Vladimir Davydov [off-list ref]
wrote:
quoted hunk
In the scope of the idle memory tracking feature, which is introduced by
the following patch, we need to clear the referenced/accessed bit not
only in primary, but also in secondary ptes. The latter is required in
order to estimate wss of KVM VMs. At the same time we want to avoid
flushing tlb, because it is quite expensive and it won't really affect
the final result.
Currently, there is no function for clearing pte young bit that would
meet our requirements, so this patch introduces one. To achieve that we
have to add a new mmu-notifier callback, clear_young, since there is no
method for testing-and-clearing a secondary pte w/o flushing tlb. The
new method is not mandatory and currently only implemented by KVM.
Signed-off-by: Vladimir Davydov <redacted>
Reviewed-by: Andres Lagar-Cavilla <redacted>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
---
include/linux/mmu_notifier.h | 44
++++++++++++++++++++++++++++++++++++++++++++
mm/mmu_notifier.c | 17 +++++++++++++++++
virt/kvm/kvm_main.c | 18 ++++++++++++++++++
3 files changed, 79 insertions(+)
the
+ * latter, it is supposed to test-and-clear the young/accessed
bitflag
+ * in the secondary pte, but it may omit flushing the secondary
tlb.
+ */
+ int (*clear_young)(struct mmu_notifier *mn,
+ struct mm_struct *mm,
+ unsigned long start,
+ unsigned long end);
+
+ /*
* test_young is called to check the young/accessed bitflag in
* the secondary pte. This is used to know if the page is
* frequently used without actually clearing the flag or tearing
*mm);
extern int __mmu_notifier_clear_flush_young(struct mm_struct *mm,
unsigned long start,
unsigned long end);
+extern int __mmu_notifier_clear_young(struct mm_struct *mm,
+ unsigned long start,
+ unsigned long end);
extern int __mmu_notifier_test_young(struct mm_struct *mm,
unsigned long address);
extern void __mmu_notifier_change_pte(struct mm_struct *mm,
@@ -231,6 +244,15 @@ static inline int
mmu_notifier_clear_flush_young(struct mm_struct *mm,
return 0;
}
+static inline int mmu_notifier_clear_young(struct mm_struct *mm,
+ unsigned long start,
+ unsigned long end)
+{
+ if (mm_has_notifiers(mm))
+ return __mmu_notifier_clear_young(mm, start, end);
+ return 0;
+}
+
static inline int mmu_notifier_test_young(struct mm_struct *mm,
unsigned long address)
{
@@ -387,6 +387,23 @@ static int kvm_mmu_notifier_clear_flush_young(struct
mmu_notifier *mn,
return young;
}
+static int kvm_mmu_notifier_clear_young(struct mmu_notifier *mn,
+ struct mm_struct *mm,
+ unsigned long start,
+ unsigned long end)
+{
+ struct kvm *kvm = mmu_notifier_to_kvm(mn);
+ int young, idx;
+
If you need to cut out another version please add comments as to the two
issues raised:
- This doesn't proactively flush TLBs -- not obvious if it should.
- This adversely affects performance in Pre_haswell Intel EPT.
Thanks
Andres
From: Vladimir Davydov <hidden> Date: 2015-07-21 08:51:32
On Mon, Jul 20, 2015 at 11:34:21AM -0700, Andres Lagar-Cavilla wrote:
On Sun, Jul 19, 2015 at 5:31 AM, Vladimir Davydov [off-list ref]
[...]
quoted
+static int kvm_mmu_notifier_clear_young(struct mmu_notifier *mn,
+ struct mm_struct *mm,
+ unsigned long start,
+ unsigned long end)
+{
+ struct kvm *kvm = mmu_notifier_to_kvm(mn);
+ int young, idx;
+
If you need to cut out another version please add comments as to the two
issues raised:
- This doesn't proactively flush TLBs -- not obvious if it should.
- This adversely affects performance in Pre_haswell Intel EPT.
Oops, I stopped reading your e-mail in reply to the previous version of
this patch as soon as I saw the Reviewed-by tag, so I missed your
request for the comment, sorry about that.
Here it goes (incremental):
---
@@ -397,6 +397,19 @@ static int kvm_mmu_notifier_clear_young(struct mmu_notifier *mn,idx=srcu_read_lock(&kvm->srcu);spin_lock(&kvm->mmu_lock);+/*+*EventhoughwedonotflushTLB,thiswillstilladversely+*affectperformanceonpre-HaswellIntelEPT,wherethereis+*noEPTAccessBittoclearsothatwehavetoteardownEPT+*tablesinstead.Ifwefindthisunacceptable,wecanalways+*addaparametertokvm_age_hvasothatiteffectivelydoesn't+*doanythingonclear_young.+*+*AlsonotethatcurrentlyweneverissuesecondaryTLBflushes+*fromclear_young,leavingthisjobuptotheregularsystem+*cadence.Ifwefindthisinaccurate,wemightcomeupwitha+*moresophisticatedheuristiclater.+*/young=kvm_age_hva(kvm,start,end);spin_unlock(&kvm->mmu_lock);srcu_read_unlock(&kvm->srcu,idx);--
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>
From: Andres Lagar-Cavilla <hidden> Date: 2015-07-21 21:39:18
On Sun, Jul 19, 2015 at 5:31 AM, Vladimir Davydov [off-list ref]
wrote:
Hi,
This patch set introduces a new user API for tracking user memory pages
that have not been used for a given period of time. The purpose of this
is to provide the userspace with the means of tracking a workload's
working set, i.e. the set of pages that are actively used by the
workload. Knowing the working set size can be useful for partitioning
the system more efficiently, e.g. by tuning memory cgroup limits
appropriately, or for job placement within a compute cluster.
It is based on top of v4.2-rc2-mmotm-2015-07-15-16-46
It applies without conflicts to v4.2-rc2-mmotm-2015-07-17-16-04 as well
---- USE CASES ----
The unified cgroup hierarchy has memory.low and memory.high knobs, which
are defined as the low and high boundaries for the workload working set
size. However, the working set size of a workload may be unknown or
change in time. With this patch set, one can periodically estimate the
amount of memory unused by each cgroup and tune their memory.low and
memory.high parameters accordingly, therefore optimizing the overall
memory utilization.
Another use case is balancing workloads within a compute cluster.
Knowing how much memory is not really used by a workload unit may help
take a more optimal decision when considering migrating the unit to
another node within the cluster.
Also, as noted by Minchan, this would be useful for per-process reclaim
(https://lwn.net/Articles/545668/). With idle tracking, we could reclaim
idle
pages only by smart user memory manager.
---- USER API ----
The user API consists of two new proc files:
* /proc/kpageidle. This file implements a bitmap where each bit
corresponds
to a page, indexed by PFN. When the bit is set, the corresponding page
is
idle. A page is considered idle if it has not been accessed since it was
marked idle. To mark a page idle one should set the bit corresponding
to the
page by writing to the file. A value written to the file is OR-ed with
the
current bitmap value. Only user memory pages can be marked idle, for
other
page types input is silently ignored. Writing to this file beyond max
PFN
results in the ENXIO error. Only available when
CONFIG_IDLE_PAGE_TRACKING is
set.
This file can be used to estimate the amount of pages that are not
used by a particular workload as follows:
1. mark all pages of interest idle by setting corresponding bits in the
/proc/kpageidle bitmap
2. wait until the workload accesses its working set
3. read /proc/kpageidle and count the number of bits set
* /proc/kpagecgroup. This file contains a 64-bit inode number of the
memory cgroup each page is charged to, indexed by PFN. Only available
when
CONFIG_MEMCG is set.
This file can be used to find all pages (including unmapped file
pages) accounted to a particular cgroup. Using /proc/kpageidle, one
can then estimate the cgroup working set size.
For an example of using these files for estimating the amount of unused
memory pages per each memory cgroup, please see the script attached
below.
---- REASONING ----
The reason to introduce the new user API instead of using
/proc/PID/{clear_refs,smaps} is that the latter has two serious
drawbacks:
- it does not count unmapped file pages
- it affects the reclaimer logic
The new API attempts to overcome them both. For more details on how it
is achieved, please see the comment to patch 6.
---- CHANGE LOG ----
Changes in v9:
- add cond_resched to /proc/kpage* read/write loop (Andres)
- rebase on top of v4.2-rc2-mmotm-2015-07-15-16-46
And thanks for the perf report.
This series
Reviewed-by: Andres Lagar-Cavilla <redacted>
Changes in v8:
- clear referenced/accessed bit in secondary ptes while accessing
/proc/kpageidle; this is required to estimate wss of KVM VMs (Andres)
- check the young flag when collapsing a huge page
- copy idle/young flags on page migration
Changes in v7:
This iteration addresses Andres's comments to v6:
- do not reuse page_referenced for clearing idle flag, introduce a
separate function instead; this way we won't issue expensive tlb
flushes on /proc/kpageidle read/write
- propagate young/idle flags from head to tail pages on thp split
- skip compound tail pages while reading/writing /proc/kpageidle
- cleanup page_referenced_one
Changes in v6:
- Split the patch introducing page_cgroup_ino helper to ease review.
- Rebase on top of v4.1-rc7-mmotm-2015-06-09-16-55
Changes in v5:
- Fix possible race between kpageidle_clear_pte_refs() and
__page_set_anon_rmap() by checking that a page is on an LRU list
under zone->lru_lock (Minchan).
- Export idle flag via /proc/kpageflags (Minchan).
- Rebase on top of 4.1-rc3.
Changes in v4:
This iteration primarily addresses Minchan's comments to v3:
- Implement /proc/kpageidle as a bitmap instead of using u64 per each
page,
because there does not seem to be any future uses for the other 63 bits.
- Do not double-increase pra->referenced in page_referenced_one() if the
page
was young and referenced recently.
- Remove the pointless (page_count == 0) check from kpageidle_get_page().
- Rename kpageidle_clear_refs() to kpageidle_clear_pte_refs().
- Improve comments to kpageidle-related functions.
- Rebase on top of 4.1-rc2.
Note it does not address Minchan's concern of possible
__page_set_anon_rmap vs
page_referenced race (see https://lkml.org/lkml/2015/5/3/220) since it is
still
unclear if this race can really happen (see
https://lkml.org/lkml/2015/5/4/160)
Changes in v3:
- Enable CONFIG_IDLE_PAGE_TRACKING for 32 bit. Since this feature
requires two extra page flags and there is no space for them on 32
bit, page ext is used (thanks to Minchan Kim).
- Minor code cleanups and comments improved.
- Rebase on top of 4.1-rc1.
Changes in v2:
- The main difference from v1 is the API change. In v1 the user can
only set the idle flag for all pages at once, and for clearing the
Idle flag on pages accessed via page tables /proc/PID/clear_refs
should be used.
The main drawback of the v1 approach, as noted by Minchan, is that on
big machines setting the idle flag for each pages can result in CPU
bursts, which would be especially frustrating if the user only wanted
to estimate the amount of idle pages for a particular process or VMA.
With the new API a more fine-grained approach is possible: one can
read a process's /proc/PID/pagemap and set/check the Idle flag only
for those pages of the process's address space he or she is
interested in.
Another good point about the v2 API is that it is possible to limit
/proc/kpage* scanning rate when the user wants to estimate the total
number of idle pages, which is unachievable with the v1 approach.
- Make /proc/kpagecgroup return the ino of the closest online ancestor
in case the cgroup a page is charged to is offline.
- Fix /proc/PID/clear_refs not clearing Young page flag.
- Rebase on top of v4.0-rc6-mmotm-2015-04-01-14-54
v8: https://lkml.org/lkml/2015/7/15/587
v7: https://lkml.org/lkml/2015/7/11/119
v6: https://lkml.org/lkml/2015/6/12/301
v5: https://lkml.org/lkml/2015/5/12/449
v4: https://lkml.org/lkml/2015/5/7/580
v3: https://lkml.org/lkml/2015/4/28/224
v2: https://lkml.org/lkml/2015/4/7/260
v1: https://lkml.org/lkml/2015/3/18/794
---- PATCH SET STRUCTURE ----
The patch set is organized as follows:
- patch 1 adds page_cgroup_ino() helper for the sake of
/proc/kpagecgroup and patches 2-3 do related cleanup
- patch 4 adds /proc/kpagecgroup, which reports cgroup ino each page is
charged to
- patch 5 introduces a new mmu notifier callback, clear_young, which is
a lightweight version of clear_flush_young; it is used in patch 6
- patch 6 implements the idle page tracking feature, including the
userspace API, /proc/kpageidle
- patch 7 exports idle flag via /proc/kpageflags
---- SIMILAR WORKS ----
Originally, the patch for tracking idle memory was proposed back in 2011
by Michel Lespinasse (see http://lwn.net/Articles/459269/). The main
difference between Michel's patch and this one is that Michel
implemented a kernel space daemon for estimating idle memory size per
cgroup while this patch only provides the userspace with the minimal API
for doing the job, leaving the rest up to the userspace. However, they
both share the same idea of Idle/Young page flags to avoid affecting the
reclaimer logic.
---- PERFORMANCE EVALUATION ----
SPECjvm2008 (https://www.spec.org/jvm2008/) was used to evaluate the
performance impact introduced by this patch set. Three runs were carried
out:
- base: kernel without the patch
- patched: patched kernel, the feature is not used
- patched-active: patched kernel, 1 minute-period daemon is used for
tracking idle memory
For tracking idle memory, idlememstat utility was used:
https://github.com/locker/idlememstat
testcase base patched patched-active
compiler 537.40 ( 0.00)% 532.26 (-0.96)% 538.31 ( 0.17)%
compress 305.47 ( 0.00)% 301.08 (-1.44)% 300.71 (-1.56)%
crypto 284.32 ( 0.00)% 282.21 (-0.74)% 284.87 ( 0.19)%
derby 411.05 ( 0.00)% 413.44 ( 0.58)% 412.07 ( 0.25)%
mpegaudio 189.96 ( 0.00)% 190.87 ( 0.48)% 189.42 (-0.28)%
scimark.large 46.85 ( 0.00)% 46.41 (-0.94)% 47.83 ( 2.09)%
scimark.small 412.91 ( 0.00)% 415.41 ( 0.61)% 421.17 ( 2.00)%
serial 204.23 ( 0.00)% 213.46 ( 4.52)% 203.17 (-0.52)%
startup 36.76 ( 0.00)% 35.49 (-3.45)% 35.64 (-3.05)%
sunflow 115.34 ( 0.00)% 115.08 (-0.23)% 117.37 ( 1.76)%
xml 620.55 ( 0.00)% 619.95 (-0.10)% 620.39 (-0.03)%
composite 211.50 ( 0.00)% 211.15 (-0.17)% 211.67 ( 0.08)%
time idlememstat:
17.20user 65.16system 2:15:23elapsed 1%CPU (0avgtext+0avgdata
8476maxresident)k
448inputs+40outputs (1major+36052minor)pagefaults 0swaps
---- SCRIPT FOR COUNTING IDLE PAGES PER CGROUP ----
#! /usr/bin/python
#
import os
import stat
import errno
import struct
CGROUP_MOUNT = "/sys/fs/cgroup/memory"
BUFSIZE = 8 * 1024 # must be multiple of 8
def get_hugepage_size():
with open("/proc/meminfo", "r") as f:
for s in f:
k, v = s.split(":")
if k == "Hugepagesize":
return int(v.split()[0]) * 1024
PAGE_SIZE = os.sysconf("SC_PAGE_SIZE")
HUGEPAGE_SIZE = get_hugepage_size()
def set_idle():
f = open("/proc/kpageidle", "wb", BUFSIZE)
while True:
try:
f.write(struct.pack("Q", pow(2, 64) - 1))
except IOError as err:
if err.errno == errno.ENXIO:
break
raise
f.close()
def count_idle():
f_flags = open("/proc/kpageflags", "rb", BUFSIZE)
f_cgroup = open("/proc/kpagecgroup", "rb", BUFSIZE)
with open("/proc/kpageidle", "rb", BUFSIZE) as f:
while f.read(BUFSIZE): pass # update idle flag
idlememsz = {}
while True:
s1, s2 = f_flags.read(8), f_cgroup.read(8)
if not s1 or not s2:
break
flags, = struct.unpack('Q', s1)
cgino, = struct.unpack('Q', s2)
unevictable = (flags >> 18) & 1
huge = (flags >> 22) & 1
idle = (flags >> 25) & 1
if idle and not unevictable:
idlememsz[cgino] = idlememsz.get(cgino, 0) + \
(HUGEPAGE_SIZE if huge else PAGE_SIZE)
f_flags.close()
f_cgroup.close()
return idlememsz
if __name__ == "__main__":
print "Setting the idle flag for each page..."
set_idle()
raw_input("Wait until the workload accesses its working set, "
"then press Enter")
print "Counting idle pages..."
idlememsz = count_idle()
for dir, subdirs, files in os.walk(CGROUP_MOUNT):
ino = os.stat(dir)[stat.ST_INO]
print dir + ": " + str(idlememsz.get(ino, 0) / 1024) + " kB"
---- END SCRIPT ----
Comments are more than welcome.
Thanks,
Vladimir Davydov (8):
memcg: add page_cgroup_ino helper
hwpoison: use page_cgroup_ino for filtering by memcg
memcg: zap try_get_mem_cgroup_from_page
proc: add kpagecgroup file
mmu-notifier: add clear_young callback
proc: add kpageidle file
proc: export idle flag via kpageflags
proc: add cond_resched to /proc/kpage* read/write loop
Documentation/vm/pagemap.txt | 22 ++-
fs/proc/page.c | 282
+++++++++++++++++++++++++++++++++
fs/proc/task_mmu.c | 4 +-
include/linux/memcontrol.h | 10 +-
include/linux/mm.h | 98 ++++++++++++
include/linux/mmu_notifier.h | 44 +++++
include/linux/page-flags.h | 11 ++
include/linux/page_ext.h | 4 +
include/uapi/linux/kernel-page-flags.h | 1 +
mm/Kconfig | 12 ++
mm/debug.c | 4 +
mm/huge_memory.c | 11 +-
mm/hwpoison-inject.c | 5 +-
mm/memcontrol.c | 71 ++++-----
mm/memory-failure.c | 16 +-
mm/migrate.c | 5 +
mm/mmu_notifier.c | 17 ++
mm/page_ext.c | 3 +
mm/rmap.c | 5 +
mm/swap.c | 2 +
virt/kvm/kvm_main.c | 18 +++
21 files changed, 579 insertions(+), 66 deletions(-)
--
2.1.4
--
Andres Lagar-Cavilla | Google Kernel Team | andreslc@google.com
From: Andrew Morton <akpm@linux-foundation.org> Date: 2015-07-21 23:34:07
On Sun, 19 Jul 2015 15:31:09 +0300 Vladimir Davydov [off-list ref] wrote:
Hi,
This patch set introduces a new user API for tracking user memory pages
that have not been used for a given period of time. The purpose of this
is to provide the userspace with the means of tracking a workload's
working set, i.e. the set of pages that are actively used by the
workload. Knowing the working set size can be useful for partitioning
the system more efficiently, e.g. by tuning memory cgroup limits
appropriately, or for job placement within a compute cluster.
It is based on top of v4.2-rc2-mmotm-2015-07-15-16-46
It applies without conflicts to v4.2-rc2-mmotm-2015-07-17-16-04 as well
---- USE CASES ----
The unified cgroup hierarchy has memory.low and memory.high knobs, which
are defined as the low and high boundaries for the workload working set
size. However, the working set size of a workload may be unknown or
change in time. With this patch set, one can periodically estimate the
amount of memory unused by each cgroup and tune their memory.low and
memory.high parameters accordingly, therefore optimizing the overall
memory utilization.
Another use case is balancing workloads within a compute cluster.
Knowing how much memory is not really used by a workload unit may help
take a more optimal decision when considering migrating the unit to
another node within the cluster.
Also, as noted by Minchan, this would be useful for per-process reclaim
(https://lwn.net/Articles/545668/). With idle tracking, we could reclaim idle
pages only by smart user memory manager.
---- USER API ----
The user API consists of two new proc files:
* /proc/kpageidle. This file implements a bitmap where each bit corresponds
to a page, indexed by PFN.
What are the bit mappings? If I read the first byte of /proc/kpageidle
I get PFN #0 in bit zero of that byte? And the second byte of
/proc/kpageidle contains PFN #8 in its LSB, etc?
Maybe this is covered in the documentation file.
When the bit is set, the corresponding page is
idle. A page is considered idle if it has not been accessed since it was
marked idle.
Perhaps we can spell out in some detail what "accessed" means? I see
you've hooked into mark_page_accessed(), so a read from disk is an
access. What about a write to disk? And what about a page being
accessed from some random device (could hook into get_user_pages()?) Is
getting written to swap an access? When a dirty pagecache page is
written out by kswapd or direct reclaim?
This also should be in the permanent documentation.
To mark a page idle one should set the bit corresponding to the
page by writing to the file. A value written to the file is OR-ed with the
current bitmap value. Only user memory pages can be marked idle, for other
page types input is silently ignored. Writing to this file beyond max PFN
results in the ENXIO error. Only available when CONFIG_IDLE_PAGE_TRACKING is
set.
This file can be used to estimate the amount of pages that are not
used by a particular workload as follows:
1. mark all pages of interest idle by setting corresponding bits in the
/proc/kpageidle bitmap
2. wait until the workload accesses its working set
3. read /proc/kpageidle and count the number of bits set
Security implications. This interface could be used to learn about a
sensitive application by poking data at it and then observing its
memory access patterns. Perhaps this is why the proc files are
root-only (whcih I assume is sufficient). Some words here about the
security side of things and the reasoning behind the chosen permissions
would be good to have.
* /proc/kpagecgroup. This file contains a 64-bit inode number of the
memory cgroup each page is charged to, indexed by PFN.
Actually "closest online ancestor". This also should be in the
interface documentation.
Only available when CONFIG_MEMCG is set.
CONFIG_MEMCG and CONFIG_IDLE_PAGE_TRACKING I assume?
This file can be used to find all pages (including unmapped file
pages) accounted to a particular cgroup. Using /proc/kpageidle, one
can then estimate the cgroup working set size.
For an example of using these files for estimating the amount of unused
memory pages per each memory cgroup, please see the script attached
below.
Why were these put in /proc anyway? Rather than under /sys/fs/cgroup
somewhere? Presumably because /proc/kpageidle is useful in non-memcg
setups.
---- PERFORMANCE EVALUATION ----
"^___" means "end of changelog". Perhaps that should have been
"^---\n" - unclear.
Documentation/vm/pagemap.txt | 22 ++-
I think we'll need quite a lot more than this to fully describe the
interface?
--
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>
From: Andrew Morton <akpm@linux-foundation.org> Date: 2015-07-21 23:34:16
On Sun, 19 Jul 2015 15:31:10 +0300 Vladimir Davydov [off-list ref] wrote:
This function returns the inode number of the closest online ancestor of
the memory cgroup a page is charged to. It is required for exporting
information about which page is charged to which cgroup to userspace,
which will be introduced by a following patch.
...
The function is racy, isn't it? There's nothing to prevent this inode
from getting torn down and potentially reallocated one nanosecond after
page_cgroup_ino() returns? If so, it is only safely usable by things
which don't care (such as procfs interfaces) and this should be
documented in some fashion.
From: Andrew Morton <akpm@linux-foundation.org> Date: 2015-07-21 23:34:33
On Sun, 19 Jul 2015 15:31:11 +0300 Vladimir Davydov [off-list ref] wrote:
Hwpoison allows to filter pages by memory cgroup ino. Currently, it
calls try_get_mem_cgroup_from_page to obtain the cgroup from a page and
then its ino using cgroup_ino, but now we have an apter method for that,
page_cgroup_ino, so use it instead.
I assume "an apter" was supposed to be "a helper"?
@@ -45,12 +45,9 @@ static int hwpoison_inject(void *data, u64 val)/**doaracycheckwithelevatedpagecount,tomakesurePG_hwpoison*willonlybesetforthetargetedowner(oronafreepage).-*Wetemporarilytakepagelockfortry_get_mem_cgroup_from_page().*memory_failure()willredothecheckreliablyinsidepagelock.*/-lock_page(hpage);err=hwpoison_filter(hpage);-unlock_page(hpage);if(err)gotoput_out;
@@ -126,7 +123,7 @@ static int pfn_inject_init(void)if(!dentry)gotofail;-#ifdef CONFIG_MEMCG_SWAP+#ifdef CONFIG_MEMCGdentry=debugfs_create_u64("corrupt-filter-memcg",0600,hwpoison_dir,&hwpoison_filter_memcg);if(!dentry)
Confused. We're changing the conditions under which this debugfs file
is created. Is this a typo or some unchangelogged thing or what?
--
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>
From: Andrew Morton <akpm@linux-foundation.org> Date: 2015-07-21 23:34:39
On Sun, 19 Jul 2015 15:31:13 +0300 Vladimir Davydov [off-list ref] wrote:
quoted hunk
/proc/kpagecgroup contains a 64-bit inode number of the memory cgroup
each page is charged to, indexed by PFN. Having this information is
useful for estimating a cgroup working set size.
The file is present if CONFIG_PROC_PAGE_MONITOR && CONFIG_MEMCG.
...
The user-facing documentation should explain that reads must be
performed in multiple-of-8 sizes.
+ while (count > 0) {
+ if (pfn_valid(pfn))
+ ppage = pfn_to_page(pfn);
+ else
+ ppage = NULL;
+
+ if (ppage)
+ ino = page_cgroup_ino(ppage);
+ else
+ ino = 0;
+
+ if (put_user(ino, out)) {
+ ret = -EFAULT;
Here we do the usual procfs violation of read() behaviour. read()
normally only returns an error if it read nothing. This code will
transfer a megabyte then return -EFAULT so userspace doesn't know that
it got that megabyte.
That's easy to fix, but procfs files do this all over the place anyway :(
--
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>
From: Andrew Morton <akpm@linux-foundation.org> Date: 2015-07-21 23:35:06
On Sun, 19 Jul 2015 15:31:16 +0300 Vladimir Davydov [off-list ref] wrote:
As noted by Minchan, a benefit of reading idle flag from
/proc/kpageflags is that one can easily filter dirty and/or unevictable
pages while estimating the size of unused memory.
Note that idle flag read from /proc/kpageflags may be stale in case the
page was accessed via a PTE, because it would be too costly to iterate
over all page mappings on each /proc/kpageflags read to provide an
up-to-date value. To make sure the flag is up-to-date one has to read
/proc/kpageidle first.
Is there any value in teaching the regular old page scanner to update
these flags? If it's doing an rmap scan anyway...
--
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>
From: Andrew Morton <akpm@linux-foundation.org> Date: 2015-07-21 23:35:41
On Sun, 19 Jul 2015 15:31:15 +0300 Vladimir Davydov [off-list ref] wrote:
Knowing the portion of memory that is not used by a certain application
or memory cgroup (idle memory) can be useful for partitioning the system
efficiently, e.g. by setting memory cgroup limits appropriately.
Currently, the only means to estimate the amount of idle memory provided
by the kernel is /proc/PID/{clear_refs,smaps}: the user can clear the
access bit for all pages mapped to a particular process by writing 1 to
clear_refs, wait for some time, and then count smaps:Referenced.
However, this method has two serious shortcomings:
- it does not count unmapped file pages
- it affects the reclaimer logic
To overcome these drawbacks, this patch introduces two new page flags,
Idle and Young, and a new proc file, /proc/kpageidle. A page's Idle flag
can only be set from userspace by setting bit in /proc/kpageidle at the
offset corresponding to the page, and it is cleared whenever the page is
accessed either through page tables (it is cleared in page_referenced()
in this case) or using the read(2) system call (mark_page_accessed()).
Thus by setting the Idle flag for pages of a particular workload, which
can be found e.g. by reading /proc/PID/pagemap, waiting for some time to
let the workload access its working set, and then reading the kpageidle
file, one can estimate the amount of pages that are not used by the
workload.
The Young page flag is used to avoid interference with the memory
reclaimer. A page's Young flag is set whenever the Access bit of a page
table entry pointing to the page is cleared by writing to kpageidle. If
page_referenced() is called on a Young page, it will add 1 to its return
value, therefore concealing the fact that the Access bit was cleared.
Note, since there is no room for extra page flags on 32 bit, this
feature uses extended page flags when compiled on 32 bit.
...
...
+static void kpageidle_clear_pte_refs(struct page *page)
+{
+ struct rmap_walk_control rwc = {
+ .rmap_one = kpageidle_clear_pte_refs_one,
+ .anon_lock = page_lock_anon_vma_read,
+ };
I think this can be static const, since `arg' is unused? That would
save some cycles and stack.
Oh. So the feature is a bit unreliable.
I'm not immediately seeing anything which would prevent us from using
plain old lock_page() here. What's going on?
So we lose up to 63 pages. Presumably max_pfn is well enough aligned
for this to not matter, dunno.
+ for (; pfn < end_pfn; pfn++) {
+ bit = pfn % KPMBITS;
+ page = kpageidle_get_page(pfn);
+ if (page) {
+ if (page_is_idle(page)) {
+ /*
+ * The page might have been referenced via a
+ * pte, in which case it is not idle. Clear
+ * refs and recheck.
+ */
+ kpageidle_clear_pte_refs(page);
+ if (page_is_idle(page))
+ idle_bitmap |= 1ULL << bit;
I don't understand what's going on here. More details, please?
--
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>
From: Vladimir Davydov <hidden> Date: 2015-07-22 09:21:29
On Tue, Jul 21, 2015 at 04:34:07PM -0700, Andrew Morton wrote:
On Sun, 19 Jul 2015 15:31:10 +0300 Vladimir Davydov [off-list ref] wrote:
quoted
This function returns the inode number of the closest online ancestor of
the memory cgroup a page is charged to. It is required for exporting
information about which page is charged to which cgroup to userspace,
which will be introduced by a following patch.
...
The function is racy, isn't it? There's nothing to prevent this inode
from getting torn down and potentially reallocated one nanosecond after
page_cgroup_ino() returns? If so, it is only safely usable by things
which don't care (such as procfs interfaces) and this should be
documented in some fashion.
From: Vladimir Davydov <hidden> Date: 2015-07-22 09:45:19
On Tue, Jul 21, 2015 at 04:34:12PM -0700, Andrew Morton wrote:
On Sun, 19 Jul 2015 15:31:11 +0300 Vladimir Davydov [off-list ref] wrote:
quoted
Hwpoison allows to filter pages by memory cgroup ino. Currently, it
calls try_get_mem_cgroup_from_page to obtain the cgroup from a page and
then its ino using cgroup_ino, but now we have an apter method for that,
page_cgroup_ino, so use it instead.
I assume "an apter" was supposed to be "a helper"?
@@ -45,12 +45,9 @@ static int hwpoison_inject(void *data, u64 val)/**doaracycheckwithelevatedpagecount,tomakesurePG_hwpoison*willonlybesetforthetargetedowner(oronafreepage).-*Wetemporarilytakepagelockfortry_get_mem_cgroup_from_page().*memory_failure()willredothecheckreliablyinsidepagelock.*/-lock_page(hpage);err=hwpoison_filter(hpage);-unlock_page(hpage);if(err)gotoput_out;
@@ -126,7 +123,7 @@ static int pfn_inject_init(void)if(!dentry)gotofail;-#ifdef CONFIG_MEMCG_SWAP+#ifdef CONFIG_MEMCGdentry=debugfs_create_u64("corrupt-filter-memcg",0600,hwpoison_dir,&hwpoison_filter_memcg);if(!dentry)
Confused. We're changing the conditions under which this debugfs file
is created. Is this a typo or some unchangelogged thing or what?
This is an unchangelogged cleanup. In fact, there had been a comment
regarding it before v6, but then it got lost. Sorry about that. The
commit message should look like this:
"""
Hwpoison allows to filter pages by memory cgroup ino. Currently, it
calls try_get_mem_cgroup_from_page to obtain the cgroup from a page and
then its ino using cgroup_ino, but now we have a helper method for that,
page_cgroup_ino, so use it instead.
This patch also loosens the hwpoison memcg filter dependency rules - it
makes it depend on CONFIG_MEMCG instead of CONFIG_MEMCG_SWAP, because
hwpoison memcg filter does not require anything (nor it used to) from
CONFIG_MEMCG_SWAP side.
"""
Or we can simply revert this cleanups if you don't like it:
---
From: Vladimir Davydov <hidden> Date: 2015-07-22 10:33:35
On Tue, Jul 21, 2015 at 04:34:33PM -0700, Andrew Morton wrote:
On Sun, 19 Jul 2015 15:31:13 +0300 Vladimir Davydov [off-list ref] wrote:
quoted
/proc/kpagecgroup contains a 64-bit inode number of the memory cgroup
each page is charged to, indexed by PFN. Having this information is
useful for estimating a cgroup working set size.
The file is present if CONFIG_PROC_PAGE_MONITOR && CONFIG_MEMCG.
...
The user-facing documentation should explain that reads must be
performed in multiple-of-8 sizes.
It does. It's in the end of Documentation/vm/pagemap.c:
: Other notes:
:
: Reading from any of the files will return -EINVAL if you are not starting
: the read on an 8-byte boundary (e.g., if you sought an odd number of bytes
: into the file), or if the size of the read is not a multiple of 8 bytes.
quoted
+ while (count > 0) {
+ if (pfn_valid(pfn))
+ ppage = pfn_to_page(pfn);
+ else
+ ppage = NULL;
+
+ if (ppage)
+ ino = page_cgroup_ino(ppage);
+ else
+ ino = 0;
+
+ if (put_user(ino, out)) {
+ ret = -EFAULT;
Here we do the usual procfs violation of read() behaviour. read()
normally only returns an error if it read nothing. This code will
transfer a megabyte then return -EFAULT so userspace doesn't know that
it got that megabyte.
Yeah, that's how it works. I did it preliminary for /proc/kpagecgroup to
work exactly like /proc/kpageflags and /proc/kpagecount.
FWIW, the man page I have on my system already warns about this
peculiarity of read(2):
: On error, -1 is returned, and errno is set appropriately. In this
: case, it is left unspecified whether the file position (if any)
: changes.
That's easy to fix, but procfs files do this all over the place anyway :(
From: Vladimir Davydov <hidden> Date: 2015-07-22 15:20:57
On Tue, Jul 21, 2015 at 04:34:52PM -0700, Andrew Morton wrote:
On Sun, 19 Jul 2015 15:31:15 +0300 Vladimir Davydov [off-list ref] wrote:
quoted
Knowing the portion of memory that is not used by a certain application
or memory cgroup (idle memory) can be useful for partitioning the system
efficiently, e.g. by setting memory cgroup limits appropriately.
Currently, the only means to estimate the amount of idle memory provided
by the kernel is /proc/PID/{clear_refs,smaps}: the user can clear the
access bit for all pages mapped to a particular process by writing 1 to
clear_refs, wait for some time, and then count smaps:Referenced.
However, this method has two serious shortcomings:
- it does not count unmapped file pages
- it affects the reclaimer logic
To overcome these drawbacks, this patch introduces two new page flags,
Idle and Young, and a new proc file, /proc/kpageidle. A page's Idle flag
can only be set from userspace by setting bit in /proc/kpageidle at the
offset corresponding to the page, and it is cleared whenever the page is
accessed either through page tables (it is cleared in page_referenced()
in this case) or using the read(2) system call (mark_page_accessed()).
Thus by setting the Idle flag for pages of a particular workload, which
can be found e.g. by reading /proc/PID/pagemap, waiting for some time to
let the workload access its working set, and then reading the kpageidle
file, one can estimate the amount of pages that are not used by the
workload.
The Young page flag is used to avoid interference with the memory
reclaimer. A page's Young flag is set whenever the Access bit of a page
table entry pointing to the page is cleared by writing to kpageidle. If
page_referenced() is called on a Young page, it will add 1 to its return
value, therefore concealing the fact that the Access bit was cleared.
Note, since there is no room for extra page flags on 32 bit, this
feature uses extended page flags when compiled on 32 bit.
...
...
+static void kpageidle_clear_pte_refs(struct page *page)
+{
+ struct rmap_walk_control rwc = {
+ .rmap_one = kpageidle_clear_pte_refs_one,
+ .anon_lock = page_lock_anon_vma_read,
+ };
I think this can be static const, since `arg' is unused? That would
save some cycles and stack.
Oh. So the feature is a bit unreliable.
I'm not immediately seeing anything which would prevent us from using
plain old lock_page() here. What's going on?
A page may be locked for quite a long period of time, e.g.
truncate_inode_pages_range() may wait until a page writeback finishes
under the page lock. Instead of stalling kpageidle scan, we'd better
move on to the next page. Of course, the result won't be 100% accurate.
In fact, it isn't accurate anyway, because we skip isolated pages,
neither can it possibly be 100% accurate, because the scan itself is not
instant so that while we are performing it the system usage pattern
might change. This new API is only supposed to give a good estimate of
memory usage pattern, which could be used as a hint for adjusting the
system configuration to improve performance.
So we lose up to 63 pages. Presumably max_pfn is well enough aligned
for this to not matter, dunno.
ALIGN(x, a) resolves to ((x + a - 1) & ~(a - 1)), which is >= x, so we
shouldn't loose anything.
quoted
+ for (; pfn < end_pfn; pfn++) {
+ bit = pfn % KPMBITS;
+ page = kpageidle_get_page(pfn);
+ if (page) {
+ if (page_is_idle(page)) {
+ /*
+ * The page might have been referenced via a
+ * pte, in which case it is not idle. Clear
+ * refs and recheck.
+ */
+ kpageidle_clear_pte_refs(page);
+ if (page_is_idle(page))
+ idle_bitmap |= 1ULL << bit;
I don't understand what's going on here. More details, please?
The output is a bitmap, which is stored as an array of 8-byte elements,
where byte order within each word is native, i.e. if page at pfn #i is
idle we need to set bit #i%64 of element #i/64 of the array. I'll
reflect this in the documentation.
From: Vladimir Davydov <hidden> Date: 2015-07-22 16:24:23
On Tue, Jul 21, 2015 at 04:34:02PM -0700, Andrew Morton wrote:
On Sun, 19 Jul 2015 15:31:09 +0300 Vladimir Davydov [off-list ref] wrote:
quoted
Hi,
This patch set introduces a new user API for tracking user memory pages
that have not been used for a given period of time. The purpose of this
is to provide the userspace with the means of tracking a workload's
working set, i.e. the set of pages that are actively used by the
workload. Knowing the working set size can be useful for partitioning
the system more efficiently, e.g. by tuning memory cgroup limits
appropriately, or for job placement within a compute cluster.
It is based on top of v4.2-rc2-mmotm-2015-07-15-16-46
It applies without conflicts to v4.2-rc2-mmotm-2015-07-17-16-04 as well
---- USE CASES ----
The unified cgroup hierarchy has memory.low and memory.high knobs, which
are defined as the low and high boundaries for the workload working set
size. However, the working set size of a workload may be unknown or
change in time. With this patch set, one can periodically estimate the
amount of memory unused by each cgroup and tune their memory.low and
memory.high parameters accordingly, therefore optimizing the overall
memory utilization.
Another use case is balancing workloads within a compute cluster.
Knowing how much memory is not really used by a workload unit may help
take a more optimal decision when considering migrating the unit to
another node within the cluster.
Also, as noted by Minchan, this would be useful for per-process reclaim
(https://lwn.net/Articles/545668/). With idle tracking, we could reclaim idle
pages only by smart user memory manager.
---- USER API ----
The user API consists of two new proc files:
* /proc/kpageidle. This file implements a bitmap where each bit corresponds
to a page, indexed by PFN.
What are the bit mappings? If I read the first byte of /proc/kpageidle
I get PFN #0 in bit zero of that byte? And the second byte of
/proc/kpageidle contains PFN #8 in its LSB, etc?
The bit mapping is an array of u64 elements. Page at pfn #i corresponds
to bit #i%64 of element #i/64. Byte order is native.
Will add this to docs.
Maybe this is covered in the documentation file.
quoted
When the bit is set, the corresponding page is
idle. A page is considered idle if it has not been accessed since it was
marked idle.
Perhaps we can spell out in some detail what "accessed" means? I see
you've hooked into mark_page_accessed(), so a read from disk is an
access. What about a write to disk? And what about a page being
accessed from some random device (could hook into get_user_pages()?) Is
getting written to swap an access? When a dirty pagecache page is
written out by kswapd or direct reclaim?
This also should be in the permanent documentation.
OK, will add.
quoted
To mark a page idle one should set the bit corresponding to the
page by writing to the file. A value written to the file is OR-ed with the
current bitmap value. Only user memory pages can be marked idle, for other
page types input is silently ignored. Writing to this file beyond max PFN
results in the ENXIO error. Only available when CONFIG_IDLE_PAGE_TRACKING is
set.
This file can be used to estimate the amount of pages that are not
used by a particular workload as follows:
1. mark all pages of interest idle by setting corresponding bits in the
/proc/kpageidle bitmap
2. wait until the workload accesses its working set
3. read /proc/kpageidle and count the number of bits set
Security implications. This interface could be used to learn about a
sensitive application by poking data at it and then observing its
memory access patterns. Perhaps this is why the proc files are
root-only (whcih I assume is sufficient).
That's one point. Another point is that if we allow unprivileged users
to access it, they may interfere with the system-wide daemon doing the
regular scan and estimating the system wss.
Some words here about the security side of things and the reasoning
behind the chosen permissions would be good to have.
quoted
* /proc/kpagecgroup. This file contains a 64-bit inode number of the
memory cgroup each page is charged to, indexed by PFN.
Actually "closest online ancestor". This also should be in the
interface documentation.
Actually, the userspace knows nothing about online/offline cgroups,
because all cgroups used to be online and charge re-parenting was used
to forcibly empty a memcg on deletion. Anyways, I'll add a note.
quoted
Only available when CONFIG_MEMCG is set.
CONFIG_MEMCG and CONFIG_IDLE_PAGE_TRACKING I assume?
No, it's present iff CONFIG_PROC_PAGE_MONITOR && CONFIG_MEMCG, because
it might be useful even w/o CONFIG_IDLE_PAGE_TRACKING, e.g. in order to
find out which memcg pages of a particular process are accounted to.
quoted
This file can be used to find all pages (including unmapped file
pages) accounted to a particular cgroup. Using /proc/kpageidle, one
can then estimate the cgroup working set size.
For an example of using these files for estimating the amount of unused
memory pages per each memory cgroup, please see the script attached
below.
Why were these put in /proc anyway? Rather than under /sys/fs/cgroup
somewhere? Presumably because /proc/kpageidle is useful in non-memcg
setups.
Yes, one might use it for estimating active wss of a single process or
the whole system.
quoted
---- PERFORMANCE EVALUATION ----
"^___" means "end of changelog". Perhaps that should have been
"^---\n" - unclear.
Sorry :-/
quoted
Documentation/vm/pagemap.txt | 22 ++-
I think we'll need quite a lot more than this to fully describe the
interface?
Agree, the documentation sucks :-( Will try to forge something more
thorough.
Thanks,
Vladimir
From: Vladimir Davydov <hidden> Date: 2015-07-22 16:25:53
On Tue, Jul 21, 2015 at 04:35:00PM -0700, Andrew Morton wrote:
On Sun, 19 Jul 2015 15:31:16 +0300 Vladimir Davydov [off-list ref] wrote:
quoted
As noted by Minchan, a benefit of reading idle flag from
/proc/kpageflags is that one can easily filter dirty and/or unevictable
pages while estimating the size of unused memory.
Note that idle flag read from /proc/kpageflags may be stale in case the
page was accessed via a PTE, because it would be too costly to iterate
over all page mappings on each /proc/kpageflags read to provide an
up-to-date value. To make sure the flag is up-to-date one has to read
/proc/kpageidle first.
Is there any value in teaching the regular old page scanner to update
these flags? If it's doing an rmap scan anyway...
I don't understand what you mean by "regular old page scanner". Could
you please elaborate?
Thanks,
Vladimir
From: Vladimir Davydov <hidden> Date: 2015-07-22 16:33:44
Hi Andrew,
Would you mind merging this incremental patch to the original one? Or
should I better resubmit the whole series with all the fixes?
On Tue, Jul 21, 2015 at 11:51:08AM +0300, Vladimir Davydov wrote:
quoted hunk
On Mon, Jul 20, 2015 at 11:34:21AM -0700, Andres Lagar-Cavilla wrote:
quoted
On Sun, Jul 19, 2015 at 5:31 AM, Vladimir Davydov [off-list ref]
[...]
quoted
quoted
+static int kvm_mmu_notifier_clear_young(struct mmu_notifier *mn,
+ struct mm_struct *mm,
+ unsigned long start,
+ unsigned long end)
+{
+ struct kvm *kvm = mmu_notifier_to_kvm(mn);
+ int young, idx;
+
If you need to cut out another version please add comments as to the two
issues raised:
- This doesn't proactively flush TLBs -- not obvious if it should.
- This adversely affects performance in Pre_haswell Intel EPT.
Oops, I stopped reading your e-mail in reply to the previous version of
this patch as soon as I saw the Reviewed-by tag, so I missed your
request for the comment, sorry about that.
Here it goes (incremental):
---
@@ -397,6 +397,19 @@ static int kvm_mmu_notifier_clear_young(struct mmu_notifier *mn,idx=srcu_read_lock(&kvm->srcu);spin_lock(&kvm->mmu_lock);+/*+*EventhoughwedonotflushTLB,thiswillstilladversely+*affectperformanceonpre-HaswellIntelEPT,wherethereis+*noEPTAccessBittoclearsothatwehavetoteardownEPT+*tablesinstead.Ifwefindthisunacceptable,wecanalways+*addaparametertokvm_age_hvasothatiteffectivelydoesn't+*doanythingonclear_young.+*+*AlsonotethatcurrentlyweneverissuesecondaryTLBflushes+*fromclear_young,leavingthisjobuptotheregularsystem+*cadence.Ifwefindthisinaccurate,wemightcomeupwitha+*moresophisticatedheuristiclater.+*/young=kvm_age_hva(kvm,start,end);spin_unlock(&kvm->mmu_lock);srcu_read_unlock(&kvm->srcu,idx);
--
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>
From: Andrew Morton <akpm@linux-foundation.org> Date: 2015-07-22 19:44:25
On Wed, 22 Jul 2015 19:25:28 +0300 Vladimir Davydov [off-list ref] wrote:
On Tue, Jul 21, 2015 at 04:35:00PM -0700, Andrew Morton wrote:
quoted
On Sun, 19 Jul 2015 15:31:16 +0300 Vladimir Davydov [off-list ref] wrote:
quoted
As noted by Minchan, a benefit of reading idle flag from
/proc/kpageflags is that one can easily filter dirty and/or unevictable
pages while estimating the size of unused memory.
Note that idle flag read from /proc/kpageflags may be stale in case the
page was accessed via a PTE, because it would be too costly to iterate
over all page mappings on each /proc/kpageflags read to provide an
up-to-date value. To make sure the flag is up-to-date one has to read
/proc/kpageidle first.
Is there any value in teaching the regular old page scanner to update
these flags? If it's doing an rmap scan anyway...
I don't understand what you mean by "regular old page scanner". Could
you please elaborate?
Whenever kswapd or direct reclaim perform an rmap scan, take that as an
opportunity to also update PageIdle().
From: Andres Lagar-Cavilla <hidden> Date: 2015-07-22 20:46:22
In page_referenced_one:
+ if (referenced)
+ clear_page_idle(page);
Andres
On Wed, Jul 22, 2015 at 12:44 PM, Andrew Morton [off-list ref]
wrote:
On Wed, 22 Jul 2015 19:25:28 +0300 Vladimir Davydov <
vdavydov@parallels.com> wrote:
quoted
On Tue, Jul 21, 2015 at 04:35:00PM -0700, Andrew Morton wrote:
quoted
On Sun, 19 Jul 2015 15:31:16 +0300 Vladimir Davydov <
vdavydov@parallels.com> wrote:
quoted
quoted
quoted
As noted by Minchan, a benefit of reading idle flag from
/proc/kpageflags is that one can easily filter dirty and/or
unevictable
quoted
quoted
quoted
pages while estimating the size of unused memory.
Note that idle flag read from /proc/kpageflags may be stale in case
the
quoted
quoted
quoted
page was accessed via a PTE, because it would be too costly to
iterate
quoted
quoted
quoted
over all page mappings on each /proc/kpageflags read to provide an
up-to-date value. To make sure the flag is up-to-date one has to read
/proc/kpageidle first.
Is there any value in teaching the regular old page scanner to update
these flags? If it's doing an rmap scan anyway...
I don't understand what you mean by "regular old page scanner". Could
you please elaborate?
Whenever kswapd or direct reclaim perform an rmap scan, take that as an
opportunity to also update PageIdle().
--
Andres Lagar-Cavilla | Google Kernel Team | andreslc@google.com
From: Paul Gortmaker <hidden> Date: 2015-07-24 14:09:00
On Sun, Jul 19, 2015 at 8:31 AM, Vladimir Davydov
[off-list ref] wrote:
Knowing the portion of memory that is not used by a certain application
or memory cgroup (idle memory) can be useful for partitioning the system
efficiently, e.g. by setting memory cgroup limits appropriately.
The version of this commit currently in linux-next breaks cris and m68k
(and maybe others). Fails with:
fs/proc/page.c:341:4: error: implicit declaration of function
'pmdp_clear_young_notify' [-Werror=implicit-function-declaration]
fs/proc/page.c:347:4: error: implicit declaration of function
'ptep_clear_young_notify' [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors
make[3]: *** [fs/proc/page.o] Error 1
make[2]: *** [fs/proc] Error 2
http://kisskb.ellerman.id.au/kisskb/buildresult/12470364/
Bisect says:
65525488fa86cda44fb6870f29e9859c974700cd is the first bad commit
commit 65525488fa86cda44fb6870f29e9859c974700cd
Author: Vladimir Davydov [off-list ref]
Date: Fri Jul 24 09:11:32 2015 +1000
proc: add kpageidle file
Paul.
--
quoted hunk
Currently, the only means to estimate the amount of idle memory provided
by the kernel is /proc/PID/{clear_refs,smaps}: the user can clear the
access bit for all pages mapped to a particular process by writing 1 to
clear_refs, wait for some time, and then count smaps:Referenced.
However, this method has two serious shortcomings:
- it does not count unmapped file pages
- it affects the reclaimer logic
To overcome these drawbacks, this patch introduces two new page flags,
Idle and Young, and a new proc file, /proc/kpageidle. A page's Idle flag
can only be set from userspace by setting bit in /proc/kpageidle at the
offset corresponding to the page, and it is cleared whenever the page is
accessed either through page tables (it is cleared in page_referenced()
in this case) or using the read(2) system call (mark_page_accessed()).
Thus by setting the Idle flag for pages of a particular workload, which
can be found e.g. by reading /proc/PID/pagemap, waiting for some time to
let the workload access its working set, and then reading the kpageidle
file, one can estimate the amount of pages that are not used by the
workload.
The Young page flag is used to avoid interference with the memory
reclaimer. A page's Young flag is set whenever the Access bit of a page
table entry pointing to the page is cleared by writing to kpageidle. If
page_referenced() is called on a Young page, it will add 1 to its return
value, therefore concealing the fact that the Access bit was cleared.
Note, since there is no room for extra page flags on 32 bit, this
feature uses extended page flags when compiled on 32 bit.
Signed-off-by: Vladimir Davydov <redacted>
---
Documentation/vm/pagemap.txt | 12 ++-
fs/proc/page.c | 218 +++++++++++++++++++++++++++++++++++++++++++
fs/proc/task_mmu.c | 4 +-
include/linux/mm.h | 98 +++++++++++++++++++
include/linux/page-flags.h | 11 +++
include/linux/page_ext.h | 4 +
mm/Kconfig | 12 +++
mm/debug.c | 4 +
mm/huge_memory.c | 11 ++-
mm/migrate.c | 5 +
mm/page_ext.c | 3 +
mm/rmap.c | 5 +
mm/swap.c | 2 +
13 files changed, 385 insertions(+), 4 deletions(-)
@@ -5,7 +5,7 @@ pagemap is a new (as of 2.6.25) set of interfaces in the kernel that allow userspace programs to examine the page tables and related information by reading files in /proc.-There are four components to pagemap:+There are five components to pagemap: * /proc/pid/pagemap. This file lets a userspace process find out which physical frame each virtual page is mapped to. It contains one 64-bit
@@ -70,6 +70,16 @@ There are four components to pagemap: memory cgroup each page is charged to, indexed by PFN. Only available when CONFIG_MEMCG is set.+ * /proc/kpageidle. This file implements a bitmap where each bit corresponds+ to a page, indexed by PFN. When the bit is set, the corresponding page is+ idle. A page is considered idle if it has not been accessed since it was+ marked idle. To mark a page idle one should set the bit corresponding to the+ page by writing to the file. A value written to the file is OR-ed with the+ current bitmap value. Only user memory pages can be marked idle, for other+ page types input is silently ignored. Writing to this file beyond max PFN+ results in the ENXIO error. Only available when CONFIG_IDLE_PAGE_TRACKING is+ set.+ Short descriptions to the page flags: 0. LOCKED
@@ -459,7 +459,7 @@ static void smaps_account(struct mem_size_stats *mss, struct page *page,mss->resident+=size;/* Accumulate the size in pages that have been accessed. */-if(young||PageReferenced(page))+if(young||page_is_young(page)||PageReferenced(page))mss->referenced+=size;mapcount=page_mapcount(page);if(mapcount>=2){
@@ -808,6 +808,7 @@ static int clear_refs_pte_range(pmd_t *pmd, unsigned long addr,/* Clear accessed and referenced bits. */pmdp_test_and_clear_young(vma,addr,pmd);+test_and_clear_page_young(page);ClearPageReferenced(page);out:spin_unlock(ptl);
@@ -2311,7 +2316,8 @@ static int __collapse_huge_page_isolate(struct vm_area_struct *vma,VM_BUG_ON_PAGE(PageLRU(page),page);/* If there is no mapped pte young don't collapse the page */-if(pte_young(pteval)||PageReferenced(page)||+if(pte_young(pteval)||+page_is_young(page)||PageReferenced(page)||mmu_notifier_test_young(vma->vm_mm,address))referenced=true;}
@@ -2738,7 +2744,8 @@ static int khugepaged_scan_pmd(struct mm_struct *mm,*/if(page_count(page)!=1+!!PageSwapCache(page))gotoout_unmap;-if(pte_young(pteval)||PageReferenced(page)||+if(pte_young(pteval)||+page_is_young(page)||PageReferenced(page)||mmu_notifier_test_young(vma->vm_mm,address))referenced=true;}
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Vladimir Davydov <hidden> Date: 2015-07-24 14:17:53
On Fri, Jul 24, 2015 at 10:08:25AM -0400, Paul Gortmaker wrote:
fs/proc/page.c:341:4: error: implicit declaration of function
'pmdp_clear_young_notify' [-Werror=implicit-function-declaration]
fs/proc/page.c:347:4: error: implicit declaration of function
'ptep_clear_young_notify' [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors
make[3]: *** [fs/proc/page.o] Error 1
make[2]: *** [fs/proc] Error 2
My bad, sorry.
It's already been reported by the kbuild-test-robot, see
[linux-next:master 3983/4215] fs/proc/page.c:332:4: error: implicit declaration of function 'pmdp_clear_young_notify'
The fix is:
From: Vladimir Davydov <redacted>
Subject: [PATCH] mmu_notifier: add missing stubs for clear_young
This is a compilation fix for !CONFIG_MMU_NOTIFIER.
Fixes: mmu-notifier-add-clear_young-callback
Signed-off-by: Vladimir Davydov <redacted>
From: Vladimir Davydov <hidden> Date: 2015-07-25 16:25:49
On Wed, Jul 22, 2015 at 07:23:53PM +0300, Vladimir Davydov wrote:
On Tue, Jul 21, 2015 at 04:34:02PM -0700, Andrew Morton wrote:
quoted
On Sun, 19 Jul 2015 15:31:09 +0300 Vladimir Davydov [off-list ref] wrote:
quoted
quoted
Documentation/vm/pagemap.txt | 22 ++-
I think we'll need quite a lot more than this to fully describe the
interface?
Agree, the documentation sucks :-( Will try to forge something more
thorough.
The incremental patch is attached. Could you please merge it into
proc-add-kpageidle-file?
---
From: Vladimir Davydov <redacted>
Subject: [PATCH] Documentation: Add idle page tracking description
Signed-off-by: Vladimir Davydov <redacted>
@@ -14,6 +14,8 @@ hugetlbpage.txt - a brief summary of hugetlbpage support in the Linux kernel. hwpoison.txt - explains what hwpoison is+idle_page_tracking.txt+ - description of the idle page tracking feature. ksm.txt - how to use the Kernel Samepage Merging feature. numa
@@ -0,0 +1,94 @@+MOTIVATION++The idle page tracking feature allows to track which memory pages are being+accessed by a workload and which are idle. This information can be useful for+estimating the workload's working set size, which, in turn, can be taken into+account when configuring the workload parameters, setting memory cgroup limits,+or deciding where to place the workload within a compute cluster.++USER API++If CONFIG_IDLE_PAGE_TRACKING was enabled on compile time, a new read-write file+is present on the proc filesystem, /proc/kpageidle.++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+mapped to bit #i%64 of array element #i/64, byte order is native. When a bit is+set, the corresponding page is idle.++A page is considered idle if it has not been accessed since it was marked idle+(for more details on what "accessed" actually means see the IMPLEMENTATION+DETAILS section). To mark a page idle one has to set the bit corresponding to+the page by writing to the file. A value written to the file is OR-ed with the+current bitmap value.++Only accesses to user memory pages are tracked. These are pages mapped to a+process address space, page cache and buffer pages, swap cache pages. For other+page types (e.g. SLAB pages) an attempt to mark a page idle is silently ignored,+and hence such pages are never reported idle.++For huge pages the idle flag is set only on the head page, so one has to read+/proc/kpageflags in order to correctly count idle huge pages.++Reading from or writing to /proc/kpageidle will return -EINVAL if you are not+starting the read/write on an 8-byte boundary, or if the size of the read/write+is not a multiple of 8 bytes. Writing to this file beyond max PFN will return+-ENXIO.++That said, in order 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 the+ /proc/kpageidle bitmap. The pages can be found by reading /proc/pid/pagemap+ if the workload is represented by a process, or by filtering out alien pages+ using /proc/kpagecgroup in case the workload is placed in a memory cgroup.++ 2. Wait until the workload accesses its working set.++ 3. Read /proc/kpageidle and count the number of bits set. If one wants to+ ignore certain types of pages, e.g. mlocked pages since they are not+ reclaimable, he or she can filter them out using /proc/kpageflags.++See Documentation/vm/pagemap.txt for more information about /proc/pid/pagemap,+/proc/kpageflags, and /proc/kpagecgroup.++IMPLEMENTATION DETAILS++The kernel internally keeps track of accesses to user memory pages in order to+reclaim unreferenced pages first on memory shortage conditions. A page is+considered referenced if it has been recently accessed via a process address+space, in which case one or more PTEs it is mapped to will have the Accessed bit+set, or marked accessed explicitly by the kernel (see mark_page_accessed()). The+latter happens when:++ - a userspace process reads or writes a page using a system call (e.g. read(2)+ or write(2))++ - a page that is used for storing filesystem buffers is read or written,+ because a process needs filesystem metadata stored in it (e.g. lists a+ directory tree)++ - a page is accessed by a device driver using get_user_pages()++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 /proc/kpageidle (see the 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 a process address space. To avoid interference with the reclaimer, which,+as noted above, uses the Accessed bit to promote actively referenced pages, one+more page flag is introduced, the Young flag. When the PTE Accessed bit is+cleared as a result of setting or updating a page's Idle flag, the Young flag+is set on the page. The reclaimer treats the Young flag as an extra PTE+Accessed bit and therefore will consider such a page as referenced.++Since the idle memory tracking feature is based on the memory reclaimer logic,+it only works with pages that are on an LRU list, other pages are silently+ignored. That means it will ignore a user memory page if it is isolated, but+since there are usually not many of them, it should not affect the overall+result noticeably. In order not to stall scanning of /proc/kpageidle, locked+pages may be skipped too.
@@ -71,15 +71,8 @@ There are five components to pagemap: memory cgroup each page is charged to, indexed by PFN. Only available when CONFIG_MEMCG is set.- * /proc/kpageidle. This file implements a bitmap where each bit corresponds- to a page, indexed by PFN. When the bit is set, the corresponding page is- idle. A page is considered idle if it has not been accessed since it was- marked idle. To mark a page idle one should set the bit corresponding to the- page by writing to the file. A value written to the file is OR-ed with the- current bitmap value. Only user memory pages can be marked idle, for other- page types input is silently ignored. Writing to this file beyond max PFN- results in the ENXIO error. Only available when CONFIG_IDLE_PAGE_TRACKING is- set.+ * /proc/kpageidle. This file comprises API of the idle page tracking feature.+ See Documentation/vm/idle_page_tracking.txt for more details. Short descriptions to the page flags:
On Tue, Jul 21, 2015 at 4:34 PM, Andrew Morton
[off-list ref] wrote:
On Sun, 19 Jul 2015 15:31:09 +0300 Vladimir Davydov [off-list ref] wrote:
quoted
To mark a page idle one should set the bit corresponding to the
page by writing to the file. A value written to the file is OR-ed with the
current bitmap value. Only user memory pages can be marked idle, for other
page types input is silently ignored. Writing to this file beyond max PFN
results in the ENXIO error. Only available when CONFIG_IDLE_PAGE_TRACKING is
set.
This file can be used to estimate the amount of pages that are not
used by a particular workload as follows:
1. mark all pages of interest idle by setting corresponding bits in the
/proc/kpageidle bitmap
2. wait until the workload accesses its working set
3. read /proc/kpageidle and count the number of bits set
Security implications. This interface could be used to learn about a
sensitive application by poking data at it and then observing its
memory access patterns. Perhaps this is why the proc files are
root-only (whcih I assume is sufficient). Some words here about the
security side of things and the reasoning behind the chosen permissions
would be good to have.
As long as this stays true-root-only, I think it should be safe enough.
quoted
* /proc/kpagecgroup. This file contains a 64-bit inode number of the
memory cgroup each page is charged to, indexed by PFN.
Actually "closest online ancestor". This also should be in the
interface documentation.
quoted
Only available when CONFIG_MEMCG is set.
CONFIG_MEMCG and CONFIG_IDLE_PAGE_TRACKING I assume?
quoted
This file can be used to find all pages (including unmapped file
pages) accounted to a particular cgroup. Using /proc/kpageidle, one
can then estimate the cgroup working set size.
For an example of using these files for estimating the amount of unused
memory pages per each memory cgroup, please see the script attached
below.
Why were these put in /proc anyway? Rather than under /sys/fs/cgroup
somewhere? Presumably because /proc/kpageidle is useful in non-memcg
setups.
Do we need a /proc/vm/ for holding these kinds of things? We're
collecting a lot there. Or invent some way for this to be sensible in
/sys?
-Kees
--
Kees Cook
Chrome OS Security
Why were these put in /proc anyway? Rather than under /sys/fs/cgroup
somewhere? Presumably because /proc/kpageidle is useful in non-memcg
setups.
Do we need a /proc/vm/ for holding these kinds of things? We're
collecting a lot there. Or invent some way for this to be sensible in
/sys?
/proc is the traditional place for such things (/proc/kpagecount,
/proc/kpageflags, /proc/pagetypeinfo). But that was probably a
mistake.
/proc/sys/vm is rather a dumping ground of random tunables and
statuses, but yes, I do think that moving the kpageidle stuff into there
would be better.
From: Michal Hocko <mhocko@kernel.org> Date: 2015-07-29 12:36:36
On Sun 19-07-15 15:31:09, Vladimir Davydov wrote:
[...]
---- USER API ----
The user API consists of two new proc files:
I was thinking about this for a while. I dislike the interface. It is
quite awkward to use - e.g. you have to read the full memory to check a
single memcg idleness. This might turn out being a problem especially on
large machines. It also provides a very low level information (per-pfn
idleness) which is inherently racy. Does anybody really require this
level of detail?
I would assume that most users are interested only in a single number
which tells the idleness of the system/memcg. Well, you have mentioned
a per-process reclaim but I am quite skeptical about this.
I guess the primary reason to rely on the pfn rather than the LRU walk,
which would be more targeted (especially for memcg cases), is that we
cannot hold lru lock for the whole LRU walk and we cannot continue
walking after the lock is dropped. Maybe we can try to address that
instead? I do not think this is easy to achieve but have you considered
that as an option?
--
Michal Hocko
SUSE Labs
From: Vladimir Davydov <hidden> Date: 2015-07-29 13:59:28
On Wed, Jul 29, 2015 at 02:36:30PM +0200, Michal Hocko wrote:
On Sun 19-07-15 15:31:09, Vladimir Davydov wrote:
[...]
quoted
---- USER API ----
The user API consists of two new proc files:
I was thinking about this for a while. I dislike the interface. It is
quite awkward to use - e.g. you have to read the full memory to check a
single memcg idleness. This might turn out being a problem especially on
large machines.
Yes, with this API estimating the wss of a single memory cgroup will
cost almost as much as doing this for the whole system.
Come to think of it, does anyone really need to estimate idleness of one
particular cgroup? If we are doing this for finding an optimal memcg
limits configuration or while considering a load move within a cluster
(which I think are the primary use cases for the feature), we must do it
system-wide to see the whole picture.
It also provides a very low level information (per-pfn idleness) which
is inherently racy. Does anybody really require this level of detail?
Well, one might want to do it per-process, obtaining PFNs from
/proc/pid/pagemap.
I would assume that most users are interested only in a single number
which tells the idleness of the system/memcg.
Yes, that's what I need it for - estimating containers' wss for setting
their limits accordingly.
Well, you have mentioned a per-process reclaim but I am quite
skeptical about this.
This is what Minchan mentioned initially. Personally, I'm not going to
use it per-process, but I wouldn't rule out this use case either.
I guess the primary reason to rely on the pfn rather than the LRU walk,
which would be more targeted (especially for memcg cases), is that we
cannot hold lru lock for the whole LRU walk and we cannot continue
walking after the lock is dropped. Maybe we can try to address that
instead? I do not think this is easy to achieve but have you considered
that as an option?
Yes, I have, and I've come to a conclusion it's not doable, because LRU
lists can be constantly rotating at an arbitrary rate. If you have an
idea in mind how this could be done, please share.
Speaking of LRU-vs-PFN walk, iterating over PFNs has its own advantages:
- You can distribute a walk in time to avoid CPU bursts.
- You are free to parallelize the scanner as you wish to decrease the
scan time.
Thanks,
Vladimir
From: Michel Lespinasse <hidden> Date: 2015-07-29 14:12:16
On Wed, Jul 29, 2015 at 6:59 AM, Vladimir Davydov [off-list ref]
wrote:
quoted
I guess the primary reason to rely on the pfn rather than the LRU walk,
which would be more targeted (especially for memcg cases), is that we
cannot hold lru lock for the whole LRU walk and we cannot continue
walking after the lock is dropped. Maybe we can try to address that
instead? I do not think this is easy to achieve but have you considered
that as an option?
Yes, I have, and I've come to a conclusion it's not doable, because LRU
lists can be constantly rotating at an arbitrary rate. If you have an
idea in mind how this could be done, please share.
Speaking of LRU-vs-PFN walk, iterating over PFNs has its own advantages:
- You can distribute a walk in time to avoid CPU bursts.
- You are free to parallelize the scanner as you wish to decrease the
scan time.
There is a third way: one could go through every MM in the system and scan
their page tables. Doing things that way turns out to be generally faster
than scanning by physical address, because you don't have to go through
RMAP for every page. But, you end up needing to take the mmap_sem lock of
every MM (in turn) while scanning them, and that degrades quickly under
memory load, which is exactly when you most need this feature. So, scan by
address is still what we use here.
My only concern about the interface is that it exposes the fact that the
scan is done by address - if the interface only showed per-memcg totals, it
would make it possible to change the implementation underneath if we
somehow figure out how to work around the mmap_sem issue in the future. I
don't think that is necessarily a blocker but this is something to keep in
mind IMO.
--
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.
From: Michel Lespinasse <hidden> Date: 2015-07-29 14:13:51
(resending as text, sorry for previous post which didn't make it to the ML)
On Wed, Jul 29, 2015 at 7:12 AM, Michel Lespinasse [off-list ref] wrote:
On Wed, Jul 29, 2015 at 6:59 AM, Vladimir Davydov [off-list ref] wrote:
quoted
quoted
I guess the primary reason to rely on the pfn rather than the LRU walk,
which would be more targeted (especially for memcg cases), is that we
cannot hold lru lock for the whole LRU walk and we cannot continue
walking after the lock is dropped. Maybe we can try to address that
instead? I do not think this is easy to achieve but have you considered
that as an option?
Yes, I have, and I've come to a conclusion it's not doable, because LRU
lists can be constantly rotating at an arbitrary rate. If you have an
idea in mind how this could be done, please share.
Speaking of LRU-vs-PFN walk, iterating over PFNs has its own advantages:
- You can distribute a walk in time to avoid CPU bursts.
- You are free to parallelize the scanner as you wish to decrease the
scan time.
There is a third way: one could go through every MM in the system and scan their page tables. Doing things that way turns out to be generally faster than scanning by physical address, because you don't have to go through RMAP for every page. But, you end up needing to take the mmap_sem lock of every MM (in turn) while scanning them, and that degrades quickly under memory load, which is exactly when you most need this feature. So, scan by address is still what we use here.
My only concern about the interface is that it exposes the fact that the scan is done by address - if the interface only showed per-memcg totals, it would make it possible to change the implementation underneath if we somehow figure out how to work around the mmap_sem issue in the future. I don't think that is necessarily a blocker but this is something to keep in mind IMO.
--
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.
From: Michal Hocko <mhocko@kernel.org> Date: 2015-07-29 14:26:25
On Wed 29-07-15 16:59:07, Vladimir Davydov wrote:
On Wed, Jul 29, 2015 at 02:36:30PM +0200, Michal Hocko wrote:
quoted
On Sun 19-07-15 15:31:09, Vladimir Davydov wrote:
[...]
quoted
---- USER API ----
The user API consists of two new proc files:
I was thinking about this for a while. I dislike the interface. It is
quite awkward to use - e.g. you have to read the full memory to check a
single memcg idleness. This might turn out being a problem especially on
large machines.
Yes, with this API estimating the wss of a single memory cgroup will
cost almost as much as doing this for the whole system.
Come to think of it, does anyone really need to estimate idleness of one
particular cgroup?
It is certainly interesting for setting the low limit.
If we are doing this for finding an optimal memcg
limits configuration or while considering a load move within a cluster
(which I think are the primary use cases for the feature), we must do it
system-wide to see the whole picture.
quoted
It also provides a very low level information (per-pfn idleness) which
is inherently racy. Does anybody really require this level of detail?
Well, one might want to do it per-process, obtaining PFNs from
/proc/pid/pagemap.
Sure once the interface is exported you can do whatever ;) But my
question is whether any real usecase _requires_ it.
quoted
I would assume that most users are interested only in a single number
which tells the idleness of the system/memcg.
Yes, that's what I need it for - estimating containers' wss for setting
their limits accordingly.
So why don't we export the single per memcg and global knobs then?
This would have few advantages. First of all it would be much easier to
use, you wouldn't have to export memcg ids and finally the implementation
could be changed without any user visible changes (e.g. lru vs. pfn walks),
potential caching and who knows what. In other words. Michel had a
single number interface AFAIR, what was the primary reason to move away
from that API?
quoted
Well, you have mentioned a per-process reclaim but I am quite
skeptical about this.
This is what Minchan mentioned initially. Personally, I'm not going to
use it per-process, but I wouldn't rule out this use case either.
Considering how many times we have been bitten by too broad interfaces I
would rather be conservative.
quoted
I guess the primary reason to rely on the pfn rather than the LRU walk,
which would be more targeted (especially for memcg cases), is that we
cannot hold lru lock for the whole LRU walk and we cannot continue
walking after the lock is dropped. Maybe we can try to address that
instead? I do not think this is easy to achieve but have you considered
that as an option?
Yes, I have, and I've come to a conclusion it's not doable, because LRU
lists can be constantly rotating at an arbitrary rate. If you have an
idea in mind how this could be done, please share.
Yes this is really tricky with the current LRU implementation. I
was playing with some ideas (do some checkpoints on the way) but
none of them was really working out on a busy systems. But the LRU
implementation might change in the future. I didn't mean this as a hard
requirement it just sounds that the current implementation restrictions
shape the user visible API which is a good sign to think twice about it.
Speaking of LRU-vs-PFN walk, iterating over PFNs has its own advantages:
- You can distribute a walk in time to avoid CPU bursts.
This would make the information even more volatile. I am not sure how
helpful it would be in the end.
- You are free to parallelize the scanner as you wish to decrease the
scan time.
This is true but you could argue similar with per-node/lru threads if this
was implemented in the kernel and really needed. I am not sure it would
be really needed though. I would expect this would be a low priority
thing.
--
Michal Hocko
SUSE Labs
From: Vladimir Davydov <hidden> Date: 2015-07-29 14:45:58
On Wed, Jul 29, 2015 at 07:12:13AM -0700, Michel Lespinasse wrote:
On Wed, Jul 29, 2015 at 6:59 AM, Vladimir Davydov [off-list ref]
wrote:
quoted
quoted
I guess the primary reason to rely on the pfn rather than the LRU walk,
which would be more targeted (especially for memcg cases), is that we
cannot hold lru lock for the whole LRU walk and we cannot continue
walking after the lock is dropped. Maybe we can try to address that
instead? I do not think this is easy to achieve but have you considered
that as an option?
Yes, I have, and I've come to a conclusion it's not doable, because LRU
lists can be constantly rotating at an arbitrary rate. If you have an
idea in mind how this could be done, please share.
Speaking of LRU-vs-PFN walk, iterating over PFNs has its own advantages:
- You can distribute a walk in time to avoid CPU bursts.
- You are free to parallelize the scanner as you wish to decrease the
scan time.
There is a third way: one could go through every MM in the system and scan
their page tables. Doing things that way turns out to be generally faster
than scanning by physical address, because you don't have to go through
RMAP for every page. But, you end up needing to take the mmap_sem lock of
every MM (in turn) while scanning them, and that degrades quickly under
memory load, which is exactly when you most need this feature. So, scan by
address is still what we use here.
Page table scan approach has the inherent problem - it ignores unmapped
page cache. If a workload does a lot of read/write or map-access-unmap
operations, we won't be able to even roughly estimate its wss.
Thanks,
Vladimir
From: Michel Lespinasse <hidden> Date: 2015-07-29 15:08:23
On Wed, Jul 29, 2015 at 7:45 AM, Vladimir Davydov [off-list ref]
wrote:
Page table scan approach has the inherent problem - it ignores unmapped
page cache. If a workload does a lot of read/write or map-access-unmap
operations, we won't be able to even roughly estimate its wss.
You can catch that in mark_page_accessed on those paths, though.
--
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.
From: Michal Hocko <mhocko@kernel.org> Date: 2015-07-29 15:09:01
On Wed 29-07-15 17:45:39, Vladimir Davydov wrote:
On Wed, Jul 29, 2015 at 07:12:13AM -0700, Michel Lespinasse wrote:
quoted
On Wed, Jul 29, 2015 at 6:59 AM, Vladimir Davydov [off-list ref]
wrote:
quoted
quoted
I guess the primary reason to rely on the pfn rather than the LRU walk,
which would be more targeted (especially for memcg cases), is that we
cannot hold lru lock for the whole LRU walk and we cannot continue
walking after the lock is dropped. Maybe we can try to address that
instead? I do not think this is easy to achieve but have you considered
that as an option?
Yes, I have, and I've come to a conclusion it's not doable, because LRU
lists can be constantly rotating at an arbitrary rate. If you have an
idea in mind how this could be done, please share.
Speaking of LRU-vs-PFN walk, iterating over PFNs has its own advantages:
- You can distribute a walk in time to avoid CPU bursts.
- You are free to parallelize the scanner as you wish to decrease the
scan time.
There is a third way: one could go through every MM in the system and scan
their page tables. Doing things that way turns out to be generally faster
than scanning by physical address, because you don't have to go through
RMAP for every page. But, you end up needing to take the mmap_sem lock of
every MM (in turn) while scanning them, and that degrades quickly under
memory load, which is exactly when you most need this feature. So, scan by
address is still what we use here.
Page table scan approach has the inherent problem - it ignores unmapped
page cache. If a workload does a lot of read/write or map-access-unmap
operations, we won't be able to even roughly estimate its wss.
That page cache is trivially reclaimable if it is clean. If it needs
writeback then it is non-idle only until the next writeback. So why does
it matter for the estimation?
--
Michal Hocko
SUSE Labs
--
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>
From: Vladimir Davydov <hidden> Date: 2015-07-29 15:28:42
On Wed, Jul 29, 2015 at 04:26:19PM +0200, Michal Hocko wrote:
On Wed 29-07-15 16:59:07, Vladimir Davydov wrote:
quoted
On Wed, Jul 29, 2015 at 02:36:30PM +0200, Michal Hocko wrote:
quoted
On Sun 19-07-15 15:31:09, Vladimir Davydov wrote:
[...]
quoted
---- USER API ----
The user API consists of two new proc files:
I was thinking about this for a while. I dislike the interface. It is
quite awkward to use - e.g. you have to read the full memory to check a
single memcg idleness. This might turn out being a problem especially on
large machines.
Yes, with this API estimating the wss of a single memory cgroup will
cost almost as much as doing this for the whole system.
Come to think of it, does anyone really need to estimate idleness of one
particular cgroup?
It is certainly interesting for setting the low limit.
Yes, but IMO there is no point in setting the low limit for one
particular cgroup w/o considering what's going on with the rest of the
system.
quoted
If we are doing this for finding an optimal memcg
limits configuration or while considering a load move within a cluster
(which I think are the primary use cases for the feature), we must do it
system-wide to see the whole picture.
quoted
It also provides a very low level information (per-pfn idleness) which
is inherently racy. Does anybody really require this level of detail?
Well, one might want to do it per-process, obtaining PFNs from
/proc/pid/pagemap.
Sure once the interface is exported you can do whatever ;) But my
question is whether any real usecase _requires_ it.
I only know/care about my use case, which is memcg configuration, but I
want to make the API as reusable as possible.
quoted
quoted
I would assume that most users are interested only in a single number
which tells the idleness of the system/memcg.
Yes, that's what I need it for - estimating containers' wss for setting
their limits accordingly.
So why don't we export the single per memcg and global knobs then?
This would have few advantages. First of all it would be much easier to
use, you wouldn't have to export memcg ids and finally the implementation
could be changed without any user visible changes (e.g. lru vs. pfn walks),
potential caching and who knows what. In other words. Michel had a
single number interface AFAIR, what was the primary reason to move away
from that API?
Because there is too much to be taken care of in the kernel with such an
approach and chances are high that it won't satisfy everyone. What
should the scan period be equal too? Knob. How many kthreads do we want?
Knob. I want to keep history for last N intervals (this was a part of
Michel's implementation), what should N be equal to? Knob. I want to be
able to choose between an instant scan and a scan distributed in time.
Knob. I want to see stats for anon/locked/file/dirty memory separately,
please add them to the API. You see the scale of the problem with doing
it in the kernel?
The API this patch set introduces is simple and fair. It only defines
what "idle" flag mean and gives you a way to flip it. That's it. You
wanna history? DIY. You wanna periodic scans? DIY. Etc.
quoted
quoted
Well, you have mentioned a per-process reclaim but I am quite
skeptical about this.
This is what Minchan mentioned initially. Personally, I'm not going to
use it per-process, but I wouldn't rule out this use case either.
Considering how many times we have been bitten by too broad interfaces I
would rather be conservative.
I consider an API "broad" when it tries to do a lot of different things.
sys_prctl is a good example of a broad API.
/proc/kpageidle is not broad, because it does just one thing (I hope it
does it good :). If we attempted to implement the scanner in the kernel
with all those tunables I mentioned above, then we would get a broad API
IMO.
quoted
quoted
I guess the primary reason to rely on the pfn rather than the LRU walk,
which would be more targeted (especially for memcg cases), is that we
cannot hold lru lock for the whole LRU walk and we cannot continue
walking after the lock is dropped. Maybe we can try to address that
instead? I do not think this is easy to achieve but have you considered
that as an option?
Yes, I have, and I've come to a conclusion it's not doable, because LRU
lists can be constantly rotating at an arbitrary rate. If you have an
idea in mind how this could be done, please share.
Yes this is really tricky with the current LRU implementation. I
was playing with some ideas (do some checkpoints on the way) but
none of them was really working out on a busy systems. But the LRU
implementation might change in the future.
It might. Then we could come up with a new /proc or /sys file which
would do the same as /proc/kpageidle, but on per LRU^w whatever-it-is
basis, and give people a choice which one to use.
I didn't mean this as a hard requirement it just sounds that the
current implementation restrictions shape the user visible API which
is a good sign to think twice about it.
Agree. That's why we are discussing it now :-)
quoted
Speaking of LRU-vs-PFN walk, iterating over PFNs has its own advantages:
- You can distribute a walk in time to avoid CPU bursts.
This would make the information even more volatile. I am not sure how
helpful it would be in the end.
If you do it periodically, it is quite accurate.
quoted
- You are free to parallelize the scanner as you wish to decrease the
scan time.
This is true but you could argue similar with per-node/lru threads if this
was implemented in the kernel and really needed. I am not sure it would
be really needed though. I would expect this would be a low priority
thing.
But if you needed it one day, you'd have to extend the kernel API. With
/proc/kpageidle, you just go and fix your program.
Thanks,
Vladimir
--
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>
From: Vladimir Davydov <hidden> Date: 2015-07-29 15:31:55
On Wed, Jul 29, 2015 at 08:08:22AM -0700, Michel Lespinasse wrote:
On Wed, Jul 29, 2015 at 7:45 AM, Vladimir Davydov [off-list ref]
wrote:
quoted
Page table scan approach has the inherent problem - it ignores unmapped
page cache. If a workload does a lot of read/write or map-access-unmap
operations, we won't be able to even roughly estimate its wss.
You can catch that in mark_page_accessed on those paths, though.
Actually, the problem here is how to find an unmapped page cache page
*to mark it idle*, not to mark it accessed.
Thanks,
Vladimir
From: Michel Lespinasse <hidden> Date: 2015-07-29 15:34:54
On Wed, Jul 29, 2015 at 8:31 AM, Vladimir Davydov [off-list ref]
wrote:
On Wed, Jul 29, 2015 at 08:08:22AM -0700, Michel Lespinasse wrote:
quoted
On Wed, Jul 29, 2015 at 7:45 AM, Vladimir Davydov <
vdavydov@parallels.com>
quoted
wrote:
quoted
Page table scan approach has the inherent problem - it ignores unmapped
page cache. If a workload does a lot of read/write or map-access-unmap
operations, we won't be able to even roughly estimate its wss.
You can catch that in mark_page_accessed on those paths, though.
Actually, the problem here is how to find an unmapped page cache page
*to mark it idle*, not to mark it accessed.
Ah, yes.
When I tried that I was still scanning memory by address at the end just to
compute such totals - but I did not have to do rmap at that point anymore.
It did look incredibly lame, though.
--
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.
From: Vladimir Davydov <hidden> Date: 2015-07-29 15:36:58
On Wed, Jul 29, 2015 at 05:08:55PM +0200, Michal Hocko wrote:
On Wed 29-07-15 17:45:39, Vladimir Davydov wrote:
quoted
On Wed, Jul 29, 2015 at 07:12:13AM -0700, Michel Lespinasse wrote:
quoted
On Wed, Jul 29, 2015 at 6:59 AM, Vladimir Davydov [off-list ref]
wrote:
quoted
quoted
I guess the primary reason to rely on the pfn rather than the LRU walk,
which would be more targeted (especially for memcg cases), is that we
cannot hold lru lock for the whole LRU walk and we cannot continue
walking after the lock is dropped. Maybe we can try to address that
instead? I do not think this is easy to achieve but have you considered
that as an option?
Yes, I have, and I've come to a conclusion it's not doable, because LRU
lists can be constantly rotating at an arbitrary rate. If you have an
idea in mind how this could be done, please share.
Speaking of LRU-vs-PFN walk, iterating over PFNs has its own advantages:
- You can distribute a walk in time to avoid CPU bursts.
- You are free to parallelize the scanner as you wish to decrease the
scan time.
There is a third way: one could go through every MM in the system and scan
their page tables. Doing things that way turns out to be generally faster
than scanning by physical address, because you don't have to go through
RMAP for every page. But, you end up needing to take the mmap_sem lock of
every MM (in turn) while scanning them, and that degrades quickly under
memory load, which is exactly when you most need this feature. So, scan by
address is still what we use here.
Page table scan approach has the inherent problem - it ignores unmapped
page cache. If a workload does a lot of read/write or map-access-unmap
operations, we won't be able to even roughly estimate its wss.
That page cache is trivially reclaimable if it is clean. If it needs
writeback then it is non-idle only until the next writeback. So why does
it matter for the estimation?
Because it might be a part of a workload's working set, in which case
evicting it will make the workload lag.
Thanks,
Vladimir
From: Michal Hocko <mhocko@kernel.org> Date: 2015-07-29 15:47:24
On Wed 29-07-15 18:28:17, Vladimir Davydov wrote:
On Wed, Jul 29, 2015 at 04:26:19PM +0200, Michal Hocko wrote:
quoted
On Wed 29-07-15 16:59:07, Vladimir Davydov wrote:
quoted
On Wed, Jul 29, 2015 at 02:36:30PM +0200, Michal Hocko wrote:
quoted
On Sun 19-07-15 15:31:09, Vladimir Davydov wrote:
[...]
quoted
---- USER API ----
The user API consists of two new proc files:
I was thinking about this for a while. I dislike the interface. It is
quite awkward to use - e.g. you have to read the full memory to check a
single memcg idleness. This might turn out being a problem especially on
large machines.
Yes, with this API estimating the wss of a single memory cgroup will
cost almost as much as doing this for the whole system.
Come to think of it, does anyone really need to estimate idleness of one
particular cgroup?
It is certainly interesting for setting the low limit.
Yes, but IMO there is no point in setting the low limit for one
particular cgroup w/o considering what's going on with the rest of the
system.
If you use the low limit for isolating an important load then you do not
have to care about the others that much. All you care about is to set
the reasonable protection level and let others to compete for the rest.
[...]
quoted
quoted
quoted
I would assume that most users are interested only in a single number
which tells the idleness of the system/memcg.
Yes, that's what I need it for - estimating containers' wss for setting
their limits accordingly.
So why don't we export the single per memcg and global knobs then?
This would have few advantages. First of all it would be much easier to
use, you wouldn't have to export memcg ids and finally the implementation
could be changed without any user visible changes (e.g. lru vs. pfn walks),
potential caching and who knows what. In other words. Michel had a
single number interface AFAIR, what was the primary reason to move away
from that API?
Because there is too much to be taken care of in the kernel with such an
approach and chances are high that it won't satisfy everyone. What
should the scan period be equal too?
No, just gather the data on the read request and let the userspace
to decide when/how often etc. If we are clever enough we can cache
the numbers and prevent from the walk. Write to the file and do the
mark_idle stuff.
Knob. How many kthreads do we want?
Knob. I want to keep history for last N intervals (this was a part of
Michel's implementation), what should N be equal to? Knob.
This all relates to the kernel thread implementation which I wasn't
suggesting. I was referring to Michel's work which might induce that.
I was merely referring to a single number output. Sorry about the
confusion.
I want to be
able to choose between an instant scan and a scan distributed in time.
Knob. I want to see stats for anon/locked/file/dirty memory separately,
Why is this useful for the memcg limits setting or the wss estimation? I
can imagine that a further drop down numbers might be interesting
from the debugging POV but I fail to see what kind of decisions from
userspace you would do based on them.
[...]
quoted
Yes this is really tricky with the current LRU implementation. I
was playing with some ideas (do some checkpoints on the way) but
none of them was really working out on a busy systems. But the LRU
implementation might change in the future.
It might. Then we could come up with a new /proc or /sys file which
would do the same as /proc/kpageidle, but on per LRU^w whatever-it-is
basis, and give people a choice which one to use.
This just leads to proc files count explosion we are seeing
already... Proc ended up in dump ground for different things which
didn't fit elsewhere and I am not very much happy about it to be honest.
[...]
--
Michal Hocko
SUSE Labs
From: Andres Lagar-Cavilla <hidden> Date: 2015-07-29 15:55:07
On Wed, Jul 29, 2015 at 8:28 AM, Vladimir Davydov
[off-list ref] wrote:
On Wed, Jul 29, 2015 at 04:26:19PM +0200, Michal Hocko wrote:
quoted
On Wed 29-07-15 16:59:07, Vladimir Davydov wrote:
quoted
On Wed, Jul 29, 2015 at 02:36:30PM +0200, Michal Hocko wrote:
quoted
On Sun 19-07-15 15:31:09, Vladimir Davydov wrote:
[...]
quoted
---- USER API ----
The user API consists of two new proc files:
I was thinking about this for a while. I dislike the interface. It is
quite awkward to use - e.g. you have to read the full memory to check a
single memcg idleness. This might turn out being a problem especially on
large machines.
Yes, with this API estimating the wss of a single memory cgroup will
cost almost as much as doing this for the whole system.
Come to think of it, does anyone really need to estimate idleness of one
particular cgroup?
You can always adorn memcg with a boolean, trivially configurable from
user-space, and have all the idle computation paths skip the code if
memcg->dont_care_about_idle
quoted
It is certainly interesting for setting the low limit.
Valuable, IMHO
Yes, but IMO there is no point in setting the low limit for one
particular cgroup w/o considering what's going on with the rest of the
system.
Probably worth more fleshing out. Why not? Because global reclaim can
execute in any given context, so a noisy neighbor hurts all?
quoted
quoted
If we are doing this for finding an optimal memcg
limits configuration or while considering a load move within a cluster
(which I think are the primary use cases for the feature), we must do it
system-wide to see the whole picture.
quoted
It also provides a very low level information (per-pfn idleness) which
is inherently racy. Does anybody really require this level of detail?
It's inherently racy for antagonist workloads, but a lot of workloads
are very stable.
quoted
quoted
Well, one might want to do it per-process, obtaining PFNs from
/proc/pid/pagemap.
Sure once the interface is exported you can do whatever ;) But my
question is whether any real usecase _requires_ it.
I only know/care about my use case, which is memcg configuration, but I
want to make the API as reusable as possible.
quoted
quoted
quoted
I would assume that most users are interested only in a single number
which tells the idleness of the system/memcg.
Yes, that's what I need it for - estimating containers' wss for setting
their limits accordingly.
So why don't we export the single per memcg and global knobs then?
This would have few advantages. First of all it would be much easier to
use, you wouldn't have to export memcg ids and finally the implementation
could be changed without any user visible changes (e.g. lru vs. pfn walks),
potential caching and who knows what. In other words. Michel had a
single number interface AFAIR, what was the primary reason to move away
from that API?
Because there is too much to be taken care of in the kernel with such an
approach and chances are high that it won't satisfy everyone. What
should the scan period be equal too? Knob. How many kthreads do we want?
Knob. I want to keep history for last N intervals (this was a part of
Michel's implementation), what should N be equal to? Knob. I want to be
able to choose between an instant scan and a scan distributed in time.
Knob. I want to see stats for anon/locked/file/dirty memory separately,
please add them to the API. You see the scale of the problem with doing
it in the kernel?
The API this patch set introduces is simple and fair. It only defines
what "idle" flag mean and gives you a way to flip it. That's it. You
wanna history? DIY. You wanna periodic scans? DIY. Etc.
FTR I'm happy that the subtle internals are built with this patchset,
and the DIY is very appealing.
Andres
quoted
quoted
quoted
Well, you have mentioned a per-process reclaim but I am quite
skeptical about this.
This is what Minchan mentioned initially. Personally, I'm not going to
use it per-process, but I wouldn't rule out this use case either.
Considering how many times we have been bitten by too broad interfaces I
would rather be conservative.
I consider an API "broad" when it tries to do a lot of different things.
sys_prctl is a good example of a broad API.
/proc/kpageidle is not broad, because it does just one thing (I hope it
does it good :). If we attempted to implement the scanner in the kernel
with all those tunables I mentioned above, then we would get a broad API
IMO.
quoted
quoted
quoted
I guess the primary reason to rely on the pfn rather than the LRU walk,
which would be more targeted (especially for memcg cases), is that we
cannot hold lru lock for the whole LRU walk and we cannot continue
walking after the lock is dropped. Maybe we can try to address that
instead? I do not think this is easy to achieve but have you considered
that as an option?
Yes, I have, and I've come to a conclusion it's not doable, because LRU
lists can be constantly rotating at an arbitrary rate. If you have an
idea in mind how this could be done, please share.
Yes this is really tricky with the current LRU implementation. I
was playing with some ideas (do some checkpoints on the way) but
none of them was really working out on a busy systems. But the LRU
implementation might change in the future.
It might. Then we could come up with a new /proc or /sys file which
would do the same as /proc/kpageidle, but on per LRU^w whatever-it-is
basis, and give people a choice which one to use.
quoted
I didn't mean this as a hard requirement it just sounds that the
current implementation restrictions shape the user visible API which
is a good sign to think twice about it.
Agree. That's why we are discussing it now :-)
quoted
quoted
Speaking of LRU-vs-PFN walk, iterating over PFNs has its own advantages:
- You can distribute a walk in time to avoid CPU bursts.
This would make the information even more volatile. I am not sure how
helpful it would be in the end.
If you do it periodically, it is quite accurate.
quoted
quoted
- You are free to parallelize the scanner as you wish to decrease the
scan time.
This is true but you could argue similar with per-node/lru threads if this
was implemented in the kernel and really needed. I am not sure it would
be really needed though. I would expect this would be a low priority
thing.
But if you needed it one day, you'd have to extend the kernel API. With
/proc/kpageidle, you just go and fix your program.
Thanks,
Vladimir
--
Andres Lagar-Cavilla | Google Kernel Team | andreslc@google.com
From: Michal Hocko <mhocko@kernel.org> Date: 2015-07-29 15:58:20
On Wed 29-07-15 18:36:40, Vladimir Davydov wrote:
On Wed, Jul 29, 2015 at 05:08:55PM +0200, Michal Hocko wrote:
quoted
On Wed 29-07-15 17:45:39, Vladimir Davydov wrote:
[...]
quoted
quoted
Page table scan approach has the inherent problem - it ignores unmapped
page cache. If a workload does a lot of read/write or map-access-unmap
operations, we won't be able to even roughly estimate its wss.
That page cache is trivially reclaimable if it is clean. If it needs
writeback then it is non-idle only until the next writeback. So why does
it matter for the estimation?
Because it might be a part of a workload's working set, in which case
evicting it will make the workload lag.
My point was that no sane application will rely on the unmaped pagecache
being part of the working set. But you are right that you might have a
more complex load consisting of many applications each doing buffered
IO on the same set of files which might get evicted due to other memory
pressure in the meantime and have a higher latencies. This is where low
limit covering this memory as well might be helpful.
--
Michal Hocko
SUSE Labs
From: Vladimir Davydov <hidden> Date: 2015-07-29 16:29:29
On Wed, Jul 29, 2015 at 05:47:18PM +0200, Michal Hocko wrote:
On Wed 29-07-15 18:28:17, Vladimir Davydov wrote:
quoted
On Wed, Jul 29, 2015 at 04:26:19PM +0200, Michal Hocko wrote:
quoted
On Wed 29-07-15 16:59:07, Vladimir Davydov wrote:
quoted
On Wed, Jul 29, 2015 at 02:36:30PM +0200, Michal Hocko wrote:
quoted
On Sun 19-07-15 15:31:09, Vladimir Davydov wrote:
[...]
quoted
---- USER API ----
The user API consists of two new proc files:
I was thinking about this for a while. I dislike the interface. It is
quite awkward to use - e.g. you have to read the full memory to check a
single memcg idleness. This might turn out being a problem especially on
large machines.
Yes, with this API estimating the wss of a single memory cgroup will
cost almost as much as doing this for the whole system.
Come to think of it, does anyone really need to estimate idleness of one
particular cgroup?
It is certainly interesting for setting the low limit.
Yes, but IMO there is no point in setting the low limit for one
particular cgroup w/o considering what's going on with the rest of the
system.
If you use the low limit for isolating an important load then you do not
have to care about the others that much. All you care about is to set
the reasonable protection level and let others to compete for the rest.
That's a use case, you're right. Well, it's a natural limitation of this
API - you just have to perform a full PFN scan then. You can avoid
costly rmap walks for the cgroups you are not interested in by filtering
them out using /proc/kpagecgroup though.
[...]
quoted
quoted
quoted
quoted
I would assume that most users are interested only in a single number
which tells the idleness of the system/memcg.
Yes, that's what I need it for - estimating containers' wss for setting
their limits accordingly.
So why don't we export the single per memcg and global knobs then?
This would have few advantages. First of all it would be much easier to
use, you wouldn't have to export memcg ids and finally the implementation
could be changed without any user visible changes (e.g. lru vs. pfn walks),
potential caching and who knows what. In other words. Michel had a
single number interface AFAIR, what was the primary reason to move away
from that API?
Because there is too much to be taken care of in the kernel with such an
approach and chances are high that it won't satisfy everyone. What
should the scan period be equal too?
No, just gather the data on the read request and let the userspace
to decide when/how often etc. If we are clever enough we can cache
the numbers and prevent from the walk. Write to the file and do the
mark_idle stuff.
Still, scan rate limiting would be an issue IMO.
quoted
Knob. How many kthreads do we want?
Knob. I want to keep history for last N intervals (this was a part of
Michel's implementation), what should N be equal to? Knob.
This all relates to the kernel thread implementation which I wasn't
suggesting. I was referring to Michel's work which might induce that.
I was merely referring to a single number output. Sorry about the
confusion.
Still, what about idle stats history? I mean having info about how many
pages were idle for N scans. It might be useful for more robust/accurate
wss estimation.
quoted
I want to be
able to choose between an instant scan and a scan distributed in time.
Knob. I want to see stats for anon/locked/file/dirty memory separately,
Why is this useful for the memcg limits setting or the wss estimation? I
can imagine that a further drop down numbers might be interesting
from the debugging POV but I fail to see what kind of decisions from
userspace you would do based on them.
A couple examples that pop up in my mind:
It's difficult to make wss estimation perfect. By mlocking pages, a
workload might give a hint to the system that it will be really unhappy
if they are evicted.
One might want to consider anon pages and/or dirty pages as not idle in
order to protect them and hence avoid expensive pageout/swapout.
[...]
quoted
quoted
Yes this is really tricky with the current LRU implementation. I
was playing with some ideas (do some checkpoints on the way) but
none of them was really working out on a busy systems. But the LRU
implementation might change in the future.
It might. Then we could come up with a new /proc or /sys file which
would do the same as /proc/kpageidle, but on per LRU^w whatever-it-is
basis, and give people a choice which one to use.
This just leads to proc files count explosion we are seeing
already... Proc ended up in dump ground for different things which
didn't fit elsewhere and I am not very much happy about it to be honest.
Moving the API to memcg is not a good idea either IMO, because the
feature can actually be useful with memcg disabled, e.g. it might help
estimate if the system is over- or underloaded.
/proc/kpageidle should probably live somewhere in /sys/kernel/mm, but I
added it where similar files are located (kpagecount, kpageflags) to
keep things consistent.
Thanks,
Vladimir
From: Vladimir Davydov <hidden> Date: 2015-07-29 16:37:47
On Wed, Jul 29, 2015 at 08:55:01AM -0700, Andres Lagar-Cavilla wrote:
On Wed, Jul 29, 2015 at 8:28 AM, Vladimir Davydov
[off-list ref] wrote:
quoted
On Wed, Jul 29, 2015 at 04:26:19PM +0200, Michal Hocko wrote:
quoted
On Wed 29-07-15 16:59:07, Vladimir Davydov wrote:
quoted
On Wed, Jul 29, 2015 at 02:36:30PM +0200, Michal Hocko wrote:
quoted
On Sun 19-07-15 15:31:09, Vladimir Davydov wrote:
[...]
quoted
---- USER API ----
The user API consists of two new proc files:
I was thinking about this for a while. I dislike the interface. It is
quite awkward to use - e.g. you have to read the full memory to check a
single memcg idleness. This might turn out being a problem especially on
large machines.
Yes, with this API estimating the wss of a single memory cgroup will
cost almost as much as doing this for the whole system.
Come to think of it, does anyone really need to estimate idleness of one
particular cgroup?
You can always adorn memcg with a boolean, trivially configurable from
user-space, and have all the idle computation paths skip the code if
memcg->dont_care_about_idle
Or we can filter out cgroups in which we're not interested using
/proc/kpagecgroup.
quoted
quoted
It is certainly interesting for setting the low limit.
Valuable, IMHO
quoted
Yes, but IMO there is no point in setting the low limit for one
particular cgroup w/o considering what's going on with the rest of the
system.
Probably worth more fleshing out. Why not? Because global reclaim can
execute in any given context, so a noisy neighbor hurts all?
The low limit does not necessarily mean, the cgroup will never get
pushed below it. It will, if others feel really bad.
Also, by setting the low limit too high, you can make others thrash
constantly, which will increase IO, which, in turn, might hurt the
workload you're trying to protect. Blkio cgroup might help in this case
though.
Thanks,
Vladimir
From: Andrew Morton <akpm@linux-foundation.org> Date: 2015-07-29 21:30:19
On Wed, 29 Jul 2015 19:29:08 +0300 Vladimir Davydov [off-list ref] wrote:
/proc/kpageidle should probably live somewhere in /sys/kernel/mm, but I
added it where similar files are located (kpagecount, kpageflags) to
keep things consistent.
I think these files should be moved elsewhere. Consistency is good,
but not when we're being consistent with a bad thing.
So let's place these in /sys/kernel/mm and then start being consistent
with that?
From: Michal Hocko <mhocko@kernel.org> Date: 2015-07-30 09:07:21
On Wed 29-07-15 19:29:08, Vladimir Davydov wrote:
On Wed, Jul 29, 2015 at 05:47:18PM +0200, Michal Hocko wrote:
[...]
quoted
If you use the low limit for isolating an important load then you do not
have to care about the others that much. All you care about is to set
the reasonable protection level and let others to compete for the rest.
That's a use case, you're right. Well, it's a natural limitation of this
API - you just have to perform a full PFN scan then. You can avoid
costly rmap walks for the cgroups you are not interested in by filtering
them out using /proc/kpagecgroup though.
You still have to read through the whole memory and that is inherent to
the API and there no way for a better implementation later on other than
a new exported file.
[...]
quoted
quoted
Because there is too much to be taken care of in the kernel with such an
approach and chances are high that it won't satisfy everyone. What
should the scan period be equal too?
No, just gather the data on the read request and let the userspace
to decide when/how often etc. If we are clever enough we can cache
the numbers and prevent from the walk. Write to the file and do the
mark_idle stuff.
Still, scan rate limiting would be an issue IMO.
Not sure what you mean here. Scan rate would be defined by the userspace
by reading/writing to the knob. No background kernel thread is really
necessary.
quoted
quoted
Knob. How many kthreads do we want?
Knob. I want to keep history for last N intervals (this was a part of
Michel's implementation), what should N be equal to? Knob.
This all relates to the kernel thread implementation which I wasn't
suggesting. I was referring to Michel's work which might induce that.
I was merely referring to a single number output. Sorry about the
confusion.
Still, what about idle stats history? I mean having info about how many
pages were idle for N scans. It might be useful for more robust/accurate
wss estimation.
Why cannot userspace remember those numbers?
quoted
quoted
I want to be
able to choose between an instant scan and a scan distributed in time.
Knob. I want to see stats for anon/locked/file/dirty memory separately,
Why is this useful for the memcg limits setting or the wss estimation? I
can imagine that a further drop down numbers might be interesting
from the debugging POV but I fail to see what kind of decisions from
userspace you would do based on them.
A couple examples that pop up in my mind:
It's difficult to make wss estimation perfect. By mlocking pages, a
workload might give a hint to the system that it will be really unhappy
if they are evicted.
One might want to consider anon pages and/or dirty pages as not idle in
order to protect them and hence avoid expensive pageout/swapout.
I still seem to miss the point. How do you do that via the proposed
interface which doesn't influence the reclaim AFAIU and you do not have
means to achieve the above (except for swappiness). What am I missing?
quoted
[...]
quoted
quoted
Yes this is really tricky with the current LRU implementation. I
was playing with some ideas (do some checkpoints on the way) but
none of them was really working out on a busy systems. But the LRU
implementation might change in the future.
It might. Then we could come up with a new /proc or /sys file which
would do the same as /proc/kpageidle, but on per LRU^w whatever-it-is
basis, and give people a choice which one to use.
This just leads to proc files count explosion we are seeing
already... Proc ended up in dump ground for different things which
didn't fit elsewhere and I am not very much happy about it to be honest.
Moving the API to memcg is not a good idea either IMO, because the
feature can actually be useful with memcg disabled, e.g. it might help
estimate if the system is over- or underloaded.
I agree and that's why I was referring to memcg/global knobs.
--
Michal Hocko
SUSE Labs
From: Vladimir Davydov <hidden> Date: 2015-07-30 09:12:34
On Wed, Jul 29, 2015 at 02:30:15PM -0700, Andrew Morton wrote:
On Wed, 29 Jul 2015 19:29:08 +0300 Vladimir Davydov [off-list ref] wrote:
quoted
/proc/kpageidle should probably live somewhere in /sys/kernel/mm, but I
added it where similar files are located (kpagecount, kpageflags) to
keep things consistent.
I think these files should be moved elsewhere. Consistency is good,
but not when we're being consistent with a bad thing.
So let's place these in /sys/kernel/mm and then start being consistent
with that?
I really don't think we should separate kpagecgroup from kpagecount and
kpageflags, because they look very similar (each of them is read-only,
contains an array of u64 values referenced by PFN). Scattering these
files between different filesystems would look ugly IMO.
However, kpageidle is somewhat different (it's read-write, contains a
bitmap) so I think it's worth moving it to /sys/kernel/mm. We have to
move the code from fs/proc to mm/something then to remove dependency
from PROC_FS, which would be unnecessary. Let me give it a try.
Thanks,
Vladimir
--
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>
From: Vladimir Davydov <hidden> Date: 2015-07-30 09:31:33
On Thu, Jul 30, 2015 at 11:07:09AM +0200, Michal Hocko wrote:
On Wed 29-07-15 19:29:08, Vladimir Davydov wrote:
quoted
On Wed, Jul 29, 2015 at 05:47:18PM +0200, Michal Hocko wrote:
[...]
quoted
quoted
If you use the low limit for isolating an important load then you do not
have to care about the others that much. All you care about is to set
the reasonable protection level and let others to compete for the rest.
That's a use case, you're right. Well, it's a natural limitation of this
API - you just have to perform a full PFN scan then. You can avoid
costly rmap walks for the cgroups you are not interested in by filtering
them out using /proc/kpagecgroup though.
You still have to read through the whole memory and that is inherent to
the API and there no way for a better implementation later on other than
a new exported file.
I don't deny that. Nevertheless, PFN-walk is something that will always
be useful, simply because PFN-range is an invariant - it will always
exist. If one day a better page iterator appear (e.g. LRU walk) and the
need for it is justified well enough, we can add one more file. Note, it
won't deprecate the original PFN map - they both can be used for
different use cases then. If we move kpageidle to /sys/kernel/mm attr
group, which I'm doing now, it will be trivial to do and won't pollute
/proc.
[...]
quoted
quoted
quoted
Because there is too much to be taken care of in the kernel with such an
approach and chances are high that it won't satisfy everyone. What
should the scan period be equal too?
No, just gather the data on the read request and let the userspace
to decide when/how often etc. If we are clever enough we can cache
the numbers and prevent from the walk. Write to the file and do the
mark_idle stuff.
Still, scan rate limiting would be an issue IMO.
Not sure what you mean here. Scan rate would be defined by the userspace
by reading/writing to the knob. No background kernel thread is really
necessary.
Nevertheless, it means more logic in the kernel (rate limiter) and a
wider interface (+ rate limit value).
quoted
quoted
quoted
Knob. How many kthreads do we want?
Knob. I want to keep history for last N intervals (this was a part of
Michel's implementation), what should N be equal to? Knob.
This all relates to the kernel thread implementation which I wasn't
suggesting. I was referring to Michel's work which might induce that.
I was merely referring to a single number output. Sorry about the
confusion.
Still, what about idle stats history? I mean having info about how many
pages were idle for N scans. It might be useful for more robust/accurate
wss estimation.
Why cannot userspace remember those numbers?
Because they must be per-page - you have to remember for how many
periods *each particular* page has been idle. To achieve this, Michel
had to introduce a byte array referenced by PFN in his work. With
kpageidle file one can store this array in the userspace.
quoted
quoted
quoted
I want to be
able to choose between an instant scan and a scan distributed in time.
Knob. I want to see stats for anon/locked/file/dirty memory separately,
Why is this useful for the memcg limits setting or the wss estimation? I
can imagine that a further drop down numbers might be interesting
from the debugging POV but I fail to see what kind of decisions from
userspace you would do based on them.
A couple examples that pop up in my mind:
It's difficult to make wss estimation perfect. By mlocking pages, a
workload might give a hint to the system that it will be really unhappy
if they are evicted.
One might want to consider anon pages and/or dirty pages as not idle in
order to protect them and hence avoid expensive pageout/swapout.
I still seem to miss the point. How do you do that via the proposed
interface which doesn't influence the reclaim AFAIU and you do not have
means to achieve the above (except for swappiness). What am I missing?
You can consider idle only those pages that are clean, and then set the
low limit appropriately for your workload. You can find out which pages
are clean by reading /proc/kpageflags. Of course, this won't stop the
reclaimer from evicting them, but it will make the reclaimer less
aggressive with respect to your workload.
Thanks,
Vladimir
From: Vladimir Davydov <hidden> Date: 2015-07-30 13:01:48
On Thu, Jul 30, 2015 at 12:12:12PM +0300, Vladimir Davydov wrote:
On Wed, Jul 29, 2015 at 02:30:15PM -0700, Andrew Morton wrote:
quoted
On Wed, 29 Jul 2015 19:29:08 +0300 Vladimir Davydov [off-list ref] wrote:
quoted
/proc/kpageidle should probably live somewhere in /sys/kernel/mm, but I
added it where similar files are located (kpagecount, kpageflags) to
keep things consistent.
I think these files should be moved elsewhere. Consistency is good,
but not when we're being consistent with a bad thing.
So let's place these in /sys/kernel/mm and then start being consistent
with that?
I really don't think we should separate kpagecgroup from kpagecount and
kpageflags, because they look very similar (each of them is read-only,
contains an array of u64 values referenced by PFN). Scattering these
files between different filesystems would look ugly IMO.
However, kpageidle is somewhat different (it's read-write, contains a
bitmap) so I think it's worth moving it to /sys/kernel/mm. We have to
move the code from fs/proc to mm/something then to remove dependency
from PROC_FS, which would be unnecessary. Let me give it a try.
Here it goes:
From: Vladimir Davydov <redacted>
Subject: [PATCH] Move /proc/kpageidle to /sys/kernel/mm/page_idle/bitmap
Since IDLE_PAGE_TRACKING does not need to depend on PROC_FS anymore,
this patch also moves the code from fs/proc/page.c to mm/page_idle.c and
introduces a dedicated header file include/linux/page_idle.h.
Signed-off-by: Vladimir Davydov <redacted>
@@ -6,10 +6,12 @@ estimating the workload's working set size, which, in turn, can be taken into account when configuring the workload parameters, setting memory cgroup limits, or deciding where to place the workload within a compute cluster.+It is enabled by CONFIG_IDLE_PAGE_TRACKING=y.+ USER API-If CONFIG_IDLE_PAGE_TRACKING was enabled on compile time, a new read-write file-is present on the proc filesystem, /proc/kpageidle.+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. 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
@@ -30,24 +32,25 @@ and hence such pages are never reported idle. For huge pages the idle flag is set only on the head page, so one has to read /proc/kpageflags in order to correctly count idle huge pages.-Reading from or writing to /proc/kpageidle will return -EINVAL if you are not-starting the read/write on an 8-byte boundary, or if the size of the read/write-is not a multiple of 8 bytes. Writing to this file beyond max PFN will return--ENXIO.+Reading from or writing to /sys/kernel/mm/page_idle/bitmap will return+-EINVAL if you are not starting the read/write on an 8-byte boundary, or+if the size of the read/write is not a multiple of 8 bytes. Writing to+this file beyond max PFN will return -ENXIO. That said, in order 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 the- /proc/kpageidle bitmap. The pages can be found by reading /proc/pid/pagemap- if the workload is represented by a process, or by filtering out alien pages- using /proc/kpagecgroup in case the workload is placed in a memory cgroup.+ 1. Mark all the workload's pages as idle by setting corresponding bits in+ /sys/kernel/mm/page_idle/bitmap. The pages can be found by reading+ /proc/pid/pagemap if the workload is represented by a process, or by+ filtering out alien pages using /proc/kpagecgroup in case the workload is+ placed in a memory cgroup. 2. Wait until the workload accesses its working set.- 3. Read /proc/kpageidle and count the number of bits set. If one wants to- ignore certain types of pages, e.g. mlocked pages since they are not- reclaimable, he or she can filter them out using /proc/kpageflags.+ 3. Read /sys/kernel/mm/page_idle/bitmap and count the number of bits set. If+ one wants to ignore certain types of pages, e.g. mlocked pages since they+ are not reclaimable, he or she can filter them out using /proc/kpageflags. See Documentation/vm/pagemap.txt for more information about /proc/pid/pagemap, /proc/kpageflags, and /proc/kpagecgroup.
@@ -74,8 +77,9 @@ 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 /proc/kpageidle (see the 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 (see the 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
@@ -90,5 +94,5 @@ Since the idle memory tracking feature is based on the memory reclaimer logic, it only works with pages that are on an LRU list, other pages are silently ignored. That means it will ignore a user memory page if it is isolated, but since there are usually not many of them, it should not affect the overall-result noticeably. In order not to stall scanning of /proc/kpageidle, locked-pages may be skipped too.+result noticeably. In order not to stall scanning of the idle page bitmap,+locked pages may be skipped too.
@@ -5,7 +5,7 @@ pagemap is a new (as of 2.6.25) set of interfaces in the kernel that allow userspace programs to examine the page tables and related information by reading files in /proc.-There are five components to pagemap:+There are four components to pagemap: * /proc/pid/pagemap. This file lets a userspace process find out which physical frame each virtual page is mapped to. It contains one 64-bit
@@ -76,9 +76,6 @@ There are five components to pagemap: memory cgroup each page is charged to, indexed by PFN. Only available when CONFIG_MEMCG is set.- * /proc/kpageidle. This file comprises API of the idle page tracking feature.- See Documentation/vm/idle_page_tracking.txt for more details.- Short descriptions to the page flags: 0. LOCKED
@@ -125,9 +122,10 @@ Short descriptions to the page flags: zero page for pfn_zero or huge_zero page 25. IDLE- page has not been accessed since it was marked idle (see /proc/kpageidle)- Note that this flag may be stale in case the page was accessed via a PTE.- To make sure the flag is up-to-date one has to read /proc/kpageidle first.+ page has not been accessed since it was marked idle (see+ Documentation/vm/idle_page_tracking.txt). Note that this flag may be+ stale in case the page was accessed via a PTE. To make sure the flag+ is up-to-date one has to read /sys/kernel/mm/page_idle/bitmap first. [IO related page flags] 1. ERROR IO error occurred
From: Vladimir Davydov <hidden> Date: 2015-07-31 09:35:19
On Thu, Jul 30, 2015 at 04:01:22PM +0300, Vladimir Davydov wrote:
On Thu, Jul 30, 2015 at 12:12:12PM +0300, Vladimir Davydov wrote:
quoted
On Wed, Jul 29, 2015 at 02:30:15PM -0700, Andrew Morton wrote:
quoted
On Wed, 29 Jul 2015 19:29:08 +0300 Vladimir Davydov [off-list ref] wrote:
quoted
/proc/kpageidle should probably live somewhere in /sys/kernel/mm, but I
added it where similar files are located (kpagecount, kpageflags) to
keep things consistent.
I think these files should be moved elsewhere. Consistency is good,
but not when we're being consistent with a bad thing.
So let's place these in /sys/kernel/mm and then start being consistent
with that?
I really don't think we should separate kpagecgroup from kpagecount and
kpageflags, because they look very similar (each of them is read-only,
contains an array of u64 values referenced by PFN). Scattering these
files between different filesystems would look ugly IMO.
However, kpageidle is somewhat different (it's read-write, contains a
bitmap) so I think it's worth moving it to /sys/kernel/mm. We have to
move the code from fs/proc to mm/something then to remove dependency
from PROC_FS, which would be unnecessary. Let me give it a try.
Here it goes:
From: Vladimir Davydov <redacted>
Subject: [PATCH] Move /proc/kpageidle to /sys/kernel/mm/page_idle/bitmap
Since it is rather difficult to merge it into proc-add-kpageidle, should
I resend the whole series with all fixes included, provided you find
this patch OK of course?
Thanks,
Vladimir