| Message ID | 20220510152847.230957-7-hannes@cmpxchg.org (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | zswap: accounting & cgroup control | expand |
Hello. On Tue, May 10, 2022 at 11:28:47AM -0400, Johannes Weiner <hannes@cmpxchg.org> wrote: > +void obj_cgroup_charge_zswap(struct obj_cgroup *objcg, size_t size) > +{ > + struct mem_cgroup *memcg; > + > + VM_WARN_ON_ONCE(!(current->flags & PF_MEMALLOC)); > + > + /* PF_MEMALLOC context, charging must succeed */ > + if (obj_cgroup_charge(objcg, GFP_KERNEL, size)) > + VM_WARN_ON_ONCE(1); IIUC, the objcg is derived from the compressed page, i.e. same memcg (reparenting neglected for now). This memcg's memory.current is then charged with the compressed object size. Do I get it right that memory.zswap.current is a subset of memory.current? (And that zswap is limited both by memory.max and memory.zswap.max?) Thanks, Michal
On Wed, May 11, 2022 at 07:32:18PM +0200, Michal Koutný wrote: > Hello. > > On Tue, May 10, 2022 at 11:28:47AM -0400, Johannes Weiner <hannes@cmpxchg.org> wrote: > > +void obj_cgroup_charge_zswap(struct obj_cgroup *objcg, size_t size) > > +{ > > + struct mem_cgroup *memcg; > > + > > + VM_WARN_ON_ONCE(!(current->flags & PF_MEMALLOC)); > > + > > + /* PF_MEMALLOC context, charging must succeed */ > > + if (obj_cgroup_charge(objcg, GFP_KERNEL, size)) > > + VM_WARN_ON_ONCE(1); > > IIUC, the objcg is derived from the compressed page, i.e. same memcg > (reparenting neglected for now). This memcg's memory.current is then > charged with the compressed object size. Correct. After which the uncompressed page is reclaimed and uncharged. So the zswapout process will reduce the charge bottom line. > Do I get it right that memory.zswap.current is a subset of memory.current? > > (And that zswap is limited both by memory.max and memory.zswap.max?) Yes. Zswap is a memory consumer, and we want the compressed part of a workload's memory to show up in the total memory footprint. memory.zswap.* are there to configure zswap policy, within the boundaries of available memory - it's by definition a subset.
On Wed, May 11, 2022 at 03:06:56PM -0400, Johannes Weiner <hannes@cmpxchg.org> wrote: > Correct. After which the uncompressed page is reclaimed and uncharged. > So the zswapout process will reduce the charge bottom line. A zswap object falling under memory.current was my first thinking, I was confused why it's exported as a separate counter memory.zswap.current (which IMO suggests disjoint counting) and it doubles a memory.stat:zswap entry. Is the separate memory.zswap.current good for anything? (Except maybe avoiding global rstat flush on memory.stat read but that'd be an undesired precendent.) (Ad the eventually reduced footprint, the transitional excursion above memcg's (or ancestor's) limit should be limited by number of parallel reclaims running (each one at most a page, right?), so it doesn't seem necessary to tackle (now).) > memory.zswap.* are there to configure zswap policy, within the > boundaries of available memory - it's by definition a subset. I see how the .max works when equal to 0 or "max". The intermediate values are more difficult to reason about. Also, I can see that on the global level, zswap is configured relatively (/sys/module/zswap/parameters/max_pool_percent). You wrote that the actual configured value is workload specific, would it be simpler to have also relative zswap limit per memcg? (Relative wrt memory.max, it'd be rather just a convenience with this simple ratio, however, it'd correspond to the top level limit. OTOH, the relatives would have counter-intuitive hierarchical behavior. I don't mean this should be changed, rather wondering why this variant was chosen.) > +bool obj_cgroup_may_zswap(struct obj_cgroup *objcg) > +{ > + struct mem_cgroup *memcg, *original_memcg; > + bool ret = true; > + > + original_memcg = get_mem_cgroup_from_objcg(objcg); > + for (memcg = original_memcg; memcg != root_mem_cgroup; > + memcg = parent_mem_cgroup(memcg)) { > + unsigned long max = READ_ONCE(memcg->zswap_max); > + unsigned long pages; > + > + if (max == PAGE_COUNTER_MAX) > + continue; > + if (max == 0) { > + ret = false; > + break; > + } > + > + cgroup_rstat_flush(memcg->css.cgroup); Here, I think it'd be better not to bypass mem_cgroup_flush_stats() (the mechanism is approximate and you traverse all ancestors anyway), i.e. mem_cgroup_flush_stats() before the loop instead of this. Thanks, Michal
Hello Michal, On Fri, May 13, 2022 at 05:14:26PM +0200, Michal Koutný wrote: > On Wed, May 11, 2022 at 03:06:56PM -0400, Johannes Weiner <hannes@cmpxchg.org> wrote: > > Correct. After which the uncompressed page is reclaimed and uncharged. > > So the zswapout process will reduce the charge bottom line. > > A zswap object falling under memory.current was my first thinking, I was > confused why it's exported as a separate counter memory.zswap.current > (which IMO suggests disjoint counting) and it doubles a > memory.stat:zswap entry. > > Is the separate memory.zswap.current good for anything? (Except maybe > avoiding global rstat flush on memory.stat read but that'd be an > undesired precendent.) Right, it's accounted as a subset rather than fully disjointed. But it is a limitable counter of its own, so I exported it as such, with a current and a max knob. This is comparable to the kmem counter in v1. From an API POV it would be quite strange to have max for a counter that has no current. Likewise it would be strange for a major memory consumer to be missing from memory.stat. > (Ad the eventually reduced footprint, the transitional excursion above > memcg's (or ancestor's) limit should be limited by number of parallel > reclaims running (each one at most a page, right?), so it doesn't seem > necessary to tackle (now).) Correct. > > memory.zswap.* are there to configure zswap policy, within the > > boundaries of available memory - it's by definition a subset. > > I see how the .max works when equal to 0 or "max". The intermediate > values are more difficult to reason about. It needs to be configured to the workload's access frequency curve, which can be done with trial-and-error (reasonable balance between zswpins and pswpins) or in a more targeted manner using tools such as page_idle, damon etc. > Also, I can see that on the global level, zswap is configured relatively > (/sys/module/zswap/parameters/max_pool_percent). > You wrote that the actual configured value is workload specific, would > it be simpler to have also relative zswap limit per memcg? > > (Relative wrt memory.max, it'd be rather just a convenience with this > simple ratio, however, it'd correspond to the top level limit. OTOH, the > relatives would have counter-intuitive hierarchical behavior. I don't > mean this should be changed, rather wondering why this variant was > chosen.) A percentage isn't a bad way to pick a global default limit for a kernel feature. But it would have been preferable if zswap had used the percentage internally and made the knob based in bytes (like min_free_kbytes for example). Because for load tuning, bytes make much more sense. That's how you measure the workingset, so a percentage is an awkward indirection. At the cgroup level, it makes even less sense: all memcg tunables are in bytes, it would be quite weird to introduce a "max" that is 0-100. Add the confusion of how percentages would propagate down the hierarchy... > > +bool obj_cgroup_may_zswap(struct obj_cgroup *objcg) > > +{ > > + struct mem_cgroup *memcg, *original_memcg; > > + bool ret = true; > > + > > + original_memcg = get_mem_cgroup_from_objcg(objcg); > > + for (memcg = original_memcg; memcg != root_mem_cgroup; > > + memcg = parent_mem_cgroup(memcg)) { > > + unsigned long max = READ_ONCE(memcg->zswap_max); > > + unsigned long pages; > > + > > + if (max == PAGE_COUNTER_MAX) > > + continue; > > + if (max == 0) { > > + ret = false; > > + break; > > + } > > + > > + cgroup_rstat_flush(memcg->css.cgroup); > > Here, I think it'd be better not to bypass mem_cgroup_flush_stats() (the > mechanism is approximate and you traverse all ancestors anyway), i.e. > mem_cgroup_flush_stats() before the loop instead of this. I don't traverse all ancestors, I bail on disabled groups and skip unlimited ones. This saves a lot of flushes in practice right now: our heaviest swapping cgroups have zswap disabled (max=0) because they're lowpri and forced to disk. Likewise, the zswap users have their zswap limit several levels down from the root, and I currently don't ever flush the higher levels (max=PAGE_COUNTER_MAX). Flushing unnecessary groups with a ratelimit doesn't sound like an improvement to me. Thanks
On Tue, May 10, 2022 at 8:29 AM Johannes Weiner <hannes@cmpxchg.org> wrote: > [...] > +void obj_cgroup_charge_zswap(struct obj_cgroup *objcg, size_t size) > +{ > + struct mem_cgroup *memcg; > + > + VM_WARN_ON_ONCE(!(current->flags & PF_MEMALLOC)); > + > + /* PF_MEMALLOC context, charging must succeed */ ) Instead of these warnings and comment why not just explicitly use memalloc_noreclaim_[save|restore]() ? > + if (obj_cgroup_charge(objcg, GFP_KERNEL, size)) Can we please make this specific charging an opt-in feature or at least provide a way to opt-out? This will impact users/providers where swap is used transparently (in terms of memory usage). Also do you want this change for v1 users as well? > + VM_WARN_ON_ONCE(1); > + > + rcu_read_lock(); > + memcg = obj_cgroup_memcg(objcg); > + mod_memcg_state(memcg, MEMCG_ZSWAP_B, size); > + mod_memcg_state(memcg, MEMCG_ZSWAPPED, 1); > + rcu_read_unlock(); > +} > +
Hello Shakeel, On Fri, May 13, 2022 at 10:23:36AM -0700, Shakeel Butt wrote: > On Tue, May 10, 2022 at 8:29 AM Johannes Weiner <hannes@cmpxchg.org> wrote: > > > [...] > > +void obj_cgroup_charge_zswap(struct obj_cgroup *objcg, size_t size) > > +{ > > + struct mem_cgroup *memcg; > > + > > + VM_WARN_ON_ONCE(!(current->flags & PF_MEMALLOC)); > > + > > + /* PF_MEMALLOC context, charging must succeed */ > ) > Instead of these warnings and comment why not just explicitly use > memalloc_noreclaim_[save|restore]() ? Should the function be called from a non-reclaim context, it should warn rather than quietly turn itself into a reclaimer. That's not a very likely mistake, but the warning documents the expectations and context of this function better. > > + if (obj_cgroup_charge(objcg, GFP_KERNEL, size)) > > Can we please make this specific charging an opt-in feature or at > least provide a way to opt-out? This will impact users/providers where > swap is used transparently (in terms of memory usage). Also do you > want this change for v1 users as well? Ah, of course, memsw! Let's opt out of v1, since this is clearly in conflict with that way of accounting. I already hadn't added interface files for v1, so it's just a matter of bypassing the charging too. Signed-of-by: Johannes Weiner <hannes@cmpxchg.org> --- diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 350012b93a95..3ab72b8160ee 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -7469,6 +7469,9 @@ bool obj_cgroup_may_zswap(struct obj_cgroup *objcg) struct mem_cgroup *memcg, *original_memcg; bool ret = true; + if (!cgroup_subsys_on_dfl(memory_cgrp_subsys)) + return true; + original_memcg = get_mem_cgroup_from_objcg(objcg); for (memcg = original_memcg; memcg != root_mem_cgroup; memcg = parent_mem_cgroup(memcg)) { @@ -7505,6 +7508,9 @@ void obj_cgroup_charge_zswap(struct obj_cgroup *objcg, size_t size) { struct mem_cgroup *memcg; + if (!cgroup_subsys_on_dfl(memory_cgrp_subsys)) + return; + VM_WARN_ON_ONCE(!(current->flags & PF_MEMALLOC)); /* PF_MEMALLOC context, charging must succeed */ @@ -7529,6 +7535,9 @@ void obj_cgroup_uncharge_zswap(struct obj_cgroup *objcg, size_t size) { struct mem_cgroup *memcg; + if (!cgroup_subsys_on_dfl(memory_cgrp_subsys)) + return; + obj_cgroup_uncharge(objcg, size); rcu_read_lock();
On Fri, May 13, 2022 at 01:08:13PM -0400, Johannes Weiner <hannes@cmpxchg.org> wrote: > Right, it's accounted as a subset rather than fully disjointed. But it > is a limitable counter of its own, so I exported it as such, with a > current and a max knob. This is comparable to the kmem counter in v1. That counter and limit didn't turn out well. I liked the analogy to writeback (and dirty limit) better. > From an API POV it would be quite strange to have max for a counter > that has no current. Likewise it would be strange for a major memory > consumer to be missing from memory.stat. My understanding would be to have all memory.stat entries as you propose, no extra .current counter and the .max knob for zswap configuration. > It needs to be configured to the workload's access frequency curve, > which can be done with trial-and-error (reasonable balance between > zswpins and pswpins) or in a more targeted manner using tools such as > page_idle, damon etc. > [...] > Because for load tuning, bytes make much more sense. That's how you > measure the workingset, so a percentage is an awkward indirection. At > the cgroup level, it makes even less sense: all memcg tunables are in > bytes, it would be quite weird to introduce a "max" that is 0-100. Add > the confusion of how percentages would propagate down the hierarchy... Thanks for the explanation. I guess there's no simple tranformation of in-kernel available information that'd allow a more semantic configuration of this value. The rather crude absolute value requires (but also simply allows) some calibration or responsive tuning. > I don't traverse all ancestors, I bail on disabled groups and skip > unlimited ones. I admit I missed that. > Flushing unnecessary groups with a ratelimit doesn't sound like an > improvement to me. Then I'm only concerned about a situation when there's a single deep memcg that undergoes both workingset_refault() and zswap querying. The latter (bare call to cgroup_rstat_flush()) won't reset stats_flush_threshold, so the former (or the async flush more likely) would attempt a flush too. The flush work (on the leaf memcg) would be done twice even though it may be within the tolerance of cumulated error the second time. This is a thing that might require attention in the future (depending on some data how it actually performs). I see how the current approach is justified. Regards, Michal
Hello Michal, On Mon, May 16, 2022 at 04:34:59PM +0200, Michal Koutný wrote: > On Fri, May 13, 2022 at 01:08:13PM -0400, Johannes Weiner <hannes@cmpxchg.org> wrote: > > Right, it's accounted as a subset rather than fully disjointed. But it > > is a limitable counter of its own, so I exported it as such, with a > > current and a max knob. This is comparable to the kmem counter in v1. > > That counter and limit didn't turn out well. I liked the analogy to > writeback (and dirty limit) better. Right, I was only talking about the design decision to add a usage knob alongside the limit. The counter failed for a different reason. > > From an API POV it would be quite strange to have max for a counter > > that has no current. Likewise it would be strange for a major memory > > consumer to be missing from memory.stat. > > My understanding would be to have all memory.stat entries as you > propose, no extra .current counter and the .max knob for zswap > configuration. There is a longer-term advantage of sticking to the usage+limit pair precedent. Even though the usage knob happens to correspond to a memory.stat item in this case, we had also discussed the possibility of breaking out a "Compressed" item in memory.stat instead, of which zswap would only be a subset. It didn't pan out this way this time - for unrelated reasons. But it's conceivable this will happen in another scenario down the line, and then you'd need a separate usage knob anyway. It's a good idea to stay consistent. There is also an immediate practical advantage. zswap is limitable, so an auto-tuning service might want to monitor its usage at a higher frequency, with a higher precision, and with a higher urgency than memory stats are ususally logged. A dedicated usage knob allows doing that. memory.stat does not: it is a bigger file that needs to be searched with a string parser for every sample; it's flushed lazily, so it can be less precise than desired; yet, when it does flush, it flushes the entire tree rather than just the target group, making it more expensive an erratic than desired as well. > > It needs to be configured to the workload's access frequency curve, > > which can be done with trial-and-error (reasonable balance between > > zswpins and pswpins) or in a more targeted manner using tools such as > > page_idle, damon etc. > > [...] > > Because for load tuning, bytes make much more sense. That's how you > > measure the workingset, so a percentage is an awkward indirection. At > > the cgroup level, it makes even less sense: all memcg tunables are in > > bytes, it would be quite weird to introduce a "max" that is 0-100. Add > > the confusion of how percentages would propagate down the hierarchy... > > Thanks for the explanation. I guess there's no simple tranformation of > in-kernel available information that'd allow a more semantic > configuration of this value. The rather crude absolute value requires > (but also simply allows) some calibration or responsive tuning. Right. If you think about it, the same can be said about the memory limit itself. It's a crude, absolute number the kernel asks of you. Yet the optimal setting depends on the workload's ever-changing access frequency histogram, the speed of the storage backend for paging and swapping, and the workload's tolerances for paging latencies. Hopefully one day we'll be able to set a pressure/latency threshold on the cgroup, and have the kernel optimally distribute the workingset across RAM, zswap, second-tier memory, and storage - preferring the cheapest and slowest possible backing for every page while meeting the SLA. The proactive reclaim and memory offloading work is pursuing this. For now, we need the interface that allows tuning and exploring from userspace. When there is something that's ready for a general purpose OS kernel, those absolute knobs won't get in the way - just like memory.max doesn't get in the way of proactive reclaim today. Anyway, I'm just outlining where I'm coming from with this. It looks like we agree on the end result. > > Flushing unnecessary groups with a ratelimit doesn't sound like an > > improvement to me. > > Then I'm only concerned about a situation when there's a single deep > memcg that undergoes both workingset_refault() and zswap querying. > The latter (bare call to cgroup_rstat_flush()) won't reset > stats_flush_threshold, so the former (or the async flush more likely) > would attempt a flush too. The flush work (on the leaf memcg) would be > done twice even though it may be within the tolerance of cumulated > error the second time. > > This is a thing that might require attention in the future (depending on > some data how it actually performs). I see how the current approach is > justified. Yes, we can optimize it should the need arise. So far it's been fine. Thanks for your thoughts, Michal.
On Mon, 16 May 2022 16:01:05 -0400 Johannes Weiner <hannes@cmpxchg.org> wrote: > > > Flushing unnecessary groups with a ratelimit doesn't sound like an > > > improvement to me. > > > > Then I'm only concerned about a situation when there's a single deep > > memcg that undergoes both workingset_refault() and zswap querying. > > The latter (bare call to cgroup_rstat_flush()) won't reset > > stats_flush_threshold, so the former (or the async flush more likely) > > would attempt a flush too. The flush work (on the leaf memcg) would be > > done twice even though it may be within the tolerance of cumulated > > error the second time. > > > > This is a thing that might require attention in the future (depending on > > some data how it actually performs). I see how the current approach is > > justified. > > Yes, we can optimize it should the need arise. So far it's been fine. > > Thanks for your thoughts, Michal. Me too. I think everything is settled here so I plan to import this series into mm-stable in a couple of days. at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/ documentation-filesystems-proc-update-meminfo-section.patch documentation-filesystems-proc-update-meminfo-section-fix.patch documentation-filesystems-proc-update-meminfo-section-fix-2.patch mm-kconfig-move-swap-and-slab-config-options-to-the-mm-section.patch mm-kconfig-group-swap-slab-hotplug-and-thp-options-into-submenus.patch mm-kconfig-group-swap-slab-hotplug-and-thp-options-into-submenus-fix.patch mm-kconfig-group-swap-slab-hotplug-and-thp-options-into-submenus-fix-fix.patch mm-kconfig-simplify-zswap-configuration.patch mm-zswap-add-basic-meminfo-and-vmstat-coverage.patch zswap-memcg-accounting.patch zswap-memcg-accounting-fix.patch zswap-memcg-accounting-fix-2.patch
On Tue, May 17, 2022 at 04:52:16PM -0700, Andrew Morton <akpm@linux-foundation.org> wrote: > On Mon, 16 May 2022 16:01:05 -0400 Johannes Weiner <hannes@cmpxchg.org> wrote: > > Thanks for your thoughts, Michal. You're welcome. The change is well-reasoned... > I think everything is settled here so I plan to import this series into > mm-stable in a couple of days. ...and makes sense with the listed fixups. Michal
diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst index 19bcd73cad03..b4c262e99b5f 100644 --- a/Documentation/admin-guide/cgroup-v2.rst +++ b/Documentation/admin-guide/cgroup-v2.rst @@ -1347,6 +1347,12 @@ PAGE_SIZE multiple when read back. Amount of cached filesystem data that is swap-backed, such as tmpfs, shm segments, shared anonymous mmap()s + zswap + Amount of memory consumed by the zswap compression backend. + + zswapped + Amount of application memory swapped out to zswap. + file_mapped Amount of cached filesystem data mapped with mmap() @@ -1537,6 +1543,21 @@ PAGE_SIZE multiple when read back. higher than the limit for an extended period of time. This reduces the impact on the workload and memory management. + memory.zswap.current + A read-only single value file which exists on non-root + cgroups. + + The total amount of memory consumed by the zswap compression + backend. + + memory.zswap.max + A read-write single value file which exists on non-root + cgroups. The default is "max". + + Zswap usage hard limit. If a cgroup's zswap pool reaches this + limit, it will refuse to take any more stores before existing + entries fault back in or are written out to disk. + memory.pressure A read-only nested-keyed file. diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h index fe580cb96683..3385ce81ecf3 100644 --- a/include/linux/memcontrol.h +++ b/include/linux/memcontrol.h @@ -35,6 +35,8 @@ enum memcg_stat_item { MEMCG_PERCPU_B, MEMCG_VMALLOC, MEMCG_KMEM, + MEMCG_ZSWAP_B, + MEMCG_ZSWAPPED, MEMCG_NR_STAT, }; @@ -252,6 +254,10 @@ struct mem_cgroup { /* Range enforcement for interrupt charges */ struct work_struct high_work; +#ifdef CONFIG_ZSWAP + unsigned long zswap_max; +#endif + unsigned long soft_limit; /* vmpressure notifications */ @@ -1264,6 +1270,10 @@ struct mem_cgroup *mem_cgroup_from_css(struct cgroup_subsys_state *css) return NULL; } +static inline void obj_cgroup_put(struct obj_cgroup *objcg) +{ +} + static inline void mem_cgroup_put(struct mem_cgroup *memcg) { } @@ -1680,6 +1690,7 @@ int __memcg_kmem_charge_page(struct page *page, gfp_t gfp, int order); void __memcg_kmem_uncharge_page(struct page *page, int order); struct obj_cgroup *get_obj_cgroup_from_current(void); +struct obj_cgroup *get_obj_cgroup_from_page(struct page *page); int obj_cgroup_charge(struct obj_cgroup *objcg, gfp_t gfp, size_t size); void obj_cgroup_uncharge(struct obj_cgroup *objcg, size_t size); @@ -1716,6 +1727,20 @@ static inline int memcg_kmem_id(struct mem_cgroup *memcg) struct mem_cgroup *mem_cgroup_from_obj(void *p); +static inline void count_objcg_event(struct obj_cgroup *objcg, + enum vm_event_item idx) +{ + struct mem_cgroup *memcg; + + if (mem_cgroup_kmem_disabled()) + return; + + rcu_read_lock(); + memcg = obj_cgroup_memcg(objcg); + count_memcg_events(memcg, idx, 1); + rcu_read_unlock(); +} + #else static inline bool mem_cgroup_kmem_disabled(void) { @@ -1742,6 +1767,11 @@ static inline void __memcg_kmem_uncharge_page(struct page *page, int order) { } +static inline struct obj_cgroup *get_obj_cgroup_from_page(struct page *page) +{ + return NULL; +} + static inline bool memcg_kmem_enabled(void) { return false; @@ -1757,6 +1787,30 @@ static inline struct mem_cgroup *mem_cgroup_from_obj(void *p) return NULL; } +static inline void count_objcg_event(struct obj_cgroup *objcg, + enum vm_event_item idx) +{ +} + #endif /* CONFIG_MEMCG_KMEM */ +#if defined(CONFIG_MEMCG_KMEM) && defined(CONFIG_ZSWAP) +bool obj_cgroup_may_zswap(struct obj_cgroup *objcg); +void obj_cgroup_charge_zswap(struct obj_cgroup *objcg, size_t size); +void obj_cgroup_uncharge_zswap(struct obj_cgroup *objcg, size_t size); +#else +static inline bool obj_cgroup_may_zswap(struct obj_cgroup *objcg) +{ + return true; +} +static inline void obj_cgroup_charge_zswap(struct obj_cgroup *objcg, + size_t size) +{ +} +static inline void obj_cgroup_uncharge_zswap(struct obj_cgroup *objcg, + size_t size) +{ +} +#endif + #endif /* _LINUX_MEMCONTROL_H */ diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 04cea4fa362a..cbb9b43bdb80 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -1398,6 +1398,10 @@ static const struct memory_stat memory_stats[] = { { "sock", MEMCG_SOCK }, { "vmalloc", MEMCG_VMALLOC }, { "shmem", NR_SHMEM }, +#ifdef CONFIG_ZSWAP + { "zswap", MEMCG_ZSWAP_B }, + { "zswapped", MEMCG_ZSWAPPED }, +#endif { "file_mapped", NR_FILE_MAPPED }, { "file_dirty", NR_FILE_DIRTY }, { "file_writeback", NR_WRITEBACK }, @@ -1432,6 +1436,7 @@ static int memcg_page_state_unit(int item) { switch (item) { case MEMCG_PERCPU_B: + case MEMCG_ZSWAP_B: case NR_SLAB_RECLAIMABLE_B: case NR_SLAB_UNRECLAIMABLE_B: case WORKINGSET_REFAULT_ANON: @@ -1512,6 +1517,13 @@ static char *memory_stat_format(struct mem_cgroup *memcg) seq_buf_printf(&s, "%s %lu\n", vm_event_name(PGLAZYFREED), memcg_events(memcg, PGLAZYFREED)); +#ifdef CONFIG_ZSWAP + seq_buf_printf(&s, "%s %lu\n", vm_event_name(ZSWPIN), + memcg_events(memcg, ZSWPIN)); + seq_buf_printf(&s, "%s %lu\n", vm_event_name(ZSWPOUT), + memcg_events(memcg, ZSWPOUT)); +#endif + #ifdef CONFIG_TRANSPARENT_HUGEPAGE seq_buf_printf(&s, "%s %lu\n", vm_event_name(THP_FAULT_ALLOC), memcg_events(memcg, THP_FAULT_ALLOC)); @@ -2883,6 +2895,19 @@ struct mem_cgroup *mem_cgroup_from_obj(void *p) return page_memcg_check(folio_page(folio, 0)); } +static struct obj_cgroup *__get_obj_cgroup_from_memcg(struct mem_cgroup *memcg) +{ + struct obj_cgroup *objcg = NULL; + + for (; memcg != root_mem_cgroup; memcg = parent_mem_cgroup(memcg)) { + objcg = rcu_dereference(memcg->objcg); + if (objcg && obj_cgroup_tryget(objcg)) + break; + objcg = NULL; + } + return objcg; +} + __always_inline struct obj_cgroup *get_obj_cgroup_from_current(void) { struct obj_cgroup *objcg = NULL; @@ -2896,15 +2921,32 @@ __always_inline struct obj_cgroup *get_obj_cgroup_from_current(void) memcg = active_memcg(); else memcg = mem_cgroup_from_task(current); - - for (; memcg != root_mem_cgroup; memcg = parent_mem_cgroup(memcg)) { - objcg = rcu_dereference(memcg->objcg); - if (objcg && obj_cgroup_tryget(objcg)) - break; - objcg = NULL; - } + objcg = __get_obj_cgroup_from_memcg(memcg); rcu_read_unlock(); + return objcg; +} + +struct obj_cgroup *get_obj_cgroup_from_page(struct page *page) +{ + struct obj_cgroup *objcg; + + if (!memcg_kmem_enabled() || memcg_kmem_bypass()) + return NULL; + if (PageMemcgKmem(page)) { + objcg = __folio_objcg(page_folio(page)); + obj_cgroup_get(objcg); + } else { + struct mem_cgroup *memcg; + + rcu_read_lock(); + memcg = __folio_memcg(page_folio(page)); + if (memcg) + objcg = __get_obj_cgroup_from_memcg(memcg); + else + objcg = NULL; + rcu_read_unlock(); + } return objcg; } @@ -5142,6 +5184,9 @@ mem_cgroup_css_alloc(struct cgroup_subsys_state *parent_css) page_counter_set_high(&memcg->memory, PAGE_COUNTER_MAX); memcg->soft_limit = PAGE_COUNTER_MAX; +#ifdef CONFIG_ZSWAP + memcg->zswap_max = PAGE_COUNTER_MAX; +#endif page_counter_set_high(&memcg->swap, PAGE_COUNTER_MAX); if (parent) { memcg->swappiness = mem_cgroup_swappiness(parent); @@ -7406,6 +7451,139 @@ static struct cftype memsw_files[] = { { }, /* terminate */ }; +#ifdef CONFIG_ZSWAP +/** + * obj_cgroup_may_zswap - check if this cgroup can zswap + * @objcg: the object cgroup + * + * Check if the hierarchical zswap limit has been reached. + * + * This doesn't check for specific headroom, and it is not atomic + * either. But with zswap, the size of the allocation is only known + * once compression has occured, and this optimistic pre-check avoids + * spending cycles on compression when there is already no room left + * or zswap is disabled altogether somewhere in the hierarchy. + */ +bool obj_cgroup_may_zswap(struct obj_cgroup *objcg) +{ + struct mem_cgroup *memcg, *original_memcg; + bool ret = true; + + original_memcg = get_mem_cgroup_from_objcg(objcg); + for (memcg = original_memcg; memcg != root_mem_cgroup; + memcg = parent_mem_cgroup(memcg)) { + unsigned long max = READ_ONCE(memcg->zswap_max); + unsigned long pages; + + if (max == PAGE_COUNTER_MAX) + continue; + if (max == 0) { + ret = false; + break; + } + + cgroup_rstat_flush(memcg->css.cgroup); + pages = memcg_page_state(memcg, MEMCG_ZSWAP_B) / PAGE_SIZE; + if (pages < max) + continue; + ret = false; + break; + } + mem_cgroup_put(original_memcg); + return ret; +} + +/** + * obj_cgroup_charge_zswap - charge compression backend memory + * @objcg: the object cgroup + * @size: size of compressed object + * + * This forces the charge after obj_cgroup_may_swap() allowed + * compression and storage in zwap for this cgroup to go ahead. + */ +void obj_cgroup_charge_zswap(struct obj_cgroup *objcg, size_t size) +{ + struct mem_cgroup *memcg; + + VM_WARN_ON_ONCE(!(current->flags & PF_MEMALLOC)); + + /* PF_MEMALLOC context, charging must succeed */ + if (obj_cgroup_charge(objcg, GFP_KERNEL, size)) + VM_WARN_ON_ONCE(1); + + rcu_read_lock(); + memcg = obj_cgroup_memcg(objcg); + mod_memcg_state(memcg, MEMCG_ZSWAP_B, size); + mod_memcg_state(memcg, MEMCG_ZSWAPPED, 1); + rcu_read_unlock(); +} + +/** + * obj_cgroup_uncharge_zswap - uncharge compression backend memory + * @objcg: the object cgroup + * @size: size of compressed object + * + * Uncharges zswap memory on page in. + */ +void obj_cgroup_uncharge_zswap(struct obj_cgroup *objcg, size_t size) +{ + struct mem_cgroup *memcg; + + obj_cgroup_uncharge(objcg, size); + + rcu_read_lock(); + memcg = obj_cgroup_memcg(objcg); + mod_memcg_state(memcg, MEMCG_ZSWAP_B, -size); + mod_memcg_state(memcg, MEMCG_ZSWAPPED, -1); + rcu_read_unlock(); +} + +static u64 zswap_current_read(struct cgroup_subsys_state *css, + struct cftype *cft) +{ + cgroup_rstat_flush(css->cgroup); + return memcg_page_state(mem_cgroup_from_css(css), MEMCG_ZSWAP_B); +} + +static int zswap_max_show(struct seq_file *m, void *v) +{ + return seq_puts_memcg_tunable(m, + READ_ONCE(mem_cgroup_from_seq(m)->zswap_max)); +} + +static ssize_t zswap_max_write(struct kernfs_open_file *of, + char *buf, size_t nbytes, loff_t off) +{ + struct mem_cgroup *memcg = mem_cgroup_from_css(of_css(of)); + unsigned long max; + int err; + + buf = strstrip(buf); + err = page_counter_memparse(buf, "max", &max); + if (err) + return err; + + xchg(&memcg->zswap_max, max); + + return nbytes; +} + +static struct cftype zswap_files[] = { + { + .name = "zswap.current", + .flags = CFTYPE_NOT_ON_ROOT, + .read_u64 = zswap_current_read, + }, + { + .name = "zswap.max", + .flags = CFTYPE_NOT_ON_ROOT, + .seq_show = zswap_max_show, + .write = zswap_max_write, + }, + { } /* terminate */ +}; +#endif /* CONFIG_ZSWAP */ + /* * If mem_cgroup_swap_init() is implemented as a subsys_initcall() * instead of a core_initcall(), this could mean cgroup_memory_noswap still @@ -7424,7 +7602,9 @@ static int __init mem_cgroup_swap_init(void) WARN_ON(cgroup_add_dfl_cftypes(&memory_cgrp_subsys, swap_files)); WARN_ON(cgroup_add_legacy_cftypes(&memory_cgrp_subsys, memsw_files)); - +#ifdef CONFIG_ZSWAP + WARN_ON(cgroup_add_dfl_cftypes(&memory_cgrp_subsys, zswap_files)); +#endif return 0; } core_initcall(mem_cgroup_swap_init); diff --git a/mm/zswap.c b/mm/zswap.c index e3c16a70f533..104835b379ec 100644 --- a/mm/zswap.c +++ b/mm/zswap.c @@ -188,6 +188,7 @@ struct zswap_entry { unsigned long handle; unsigned long value; }; + struct obj_cgroup *objcg; }; struct zswap_header { @@ -359,6 +360,10 @@ static void zswap_rb_erase(struct rb_root *root, struct zswap_entry *entry) */ static void zswap_free_entry(struct zswap_entry *entry) { + if (entry->objcg) { + obj_cgroup_uncharge_zswap(entry->objcg, entry->length); + obj_cgroup_put(entry->objcg); + } if (!entry->length) atomic_dec(&zswap_same_filled_pages); else { @@ -1096,6 +1101,8 @@ static int zswap_frontswap_store(unsigned type, pgoff_t offset, struct zswap_entry *entry, *dupentry; struct scatterlist input, output; struct crypto_acomp_ctx *acomp_ctx; + struct obj_cgroup *objcg = NULL; + struct zswap_pool *pool; int ret; unsigned int hlen, dlen = PAGE_SIZE; unsigned long handle, value; @@ -1115,17 +1122,15 @@ static int zswap_frontswap_store(unsigned type, pgoff_t offset, goto reject; } + objcg = get_obj_cgroup_from_page(page); + if (objcg && !obj_cgroup_may_zswap(objcg)) + goto shrink; + /* reclaim space if needed */ if (zswap_is_full()) { - struct zswap_pool *pool; - zswap_pool_limit_hit++; zswap_pool_reached_full = true; - pool = zswap_pool_last_get(); - if (pool) - queue_work(shrink_wq, &pool->shrink_work); - ret = -ENOMEM; - goto reject; + goto shrink; } if (zswap_pool_reached_full) { @@ -1227,6 +1232,13 @@ static int zswap_frontswap_store(unsigned type, pgoff_t offset, entry->length = dlen; insert_entry: + entry->objcg = objcg; + if (objcg) { + obj_cgroup_charge_zswap(objcg, entry->length); + /* Account before objcg ref is moved to tree */ + count_objcg_event(objcg, ZSWPOUT); + } + /* map */ spin_lock(&tree->lock); do { @@ -1253,7 +1265,16 @@ static int zswap_frontswap_store(unsigned type, pgoff_t offset, freepage: zswap_entry_cache_free(entry); reject: + if (objcg) + obj_cgroup_put(objcg); return ret; + +shrink: + pool = zswap_pool_last_get(); + if (pool) + queue_work(shrink_wq, &pool->shrink_work); + ret = -ENOMEM; + goto reject; } /* @@ -1326,6 +1347,8 @@ static int zswap_frontswap_load(unsigned type, pgoff_t offset, BUG_ON(ret); stats: count_vm_event(ZSWPIN); + if (entry->objcg) + count_objcg_event(entry->objcg, ZSWPIN); freeentry: spin_lock(&tree->lock); zswap_entry_put(tree, entry);
Applications can currently escape their cgroup memory containment when zswap is enabled. This patch adds per-cgroup tracking and limiting of zswap backend memory to rectify this. The existing cgroup2 memory.stat file is extended to show zswap statistics analogous to what's in meminfo and vmstat. Furthermore, two new control files, memory.zswap.current and memory.zswap.max, are added to allow tuning zswap usage on a per-workload basis. This is important since not all workloads benefit from zswap equally; some even suffer compared to disk swap when memory contents don't compress well. The optimal size of the zswap pool, and the threshold for writeback, also depends on the size of the workload's warm set. The implementation doesn't use a traditional page_counter transaction. zswap is unconventional as a memory consumer in that we only know the amount of memory to charge once expensive compression has occurred. If zwap is disabled or the limit is already exceeded we obviously don't want to compress page upon page only to reject them all. Instead, the limit is checked against current usage, then we compress and charge. This allows some limit overrun, but not enough to matter in practice. Signed-off-by: Johannes Weiner <hannes@cmpxchg.org> --- Documentation/admin-guide/cgroup-v2.rst | 21 +++ include/linux/memcontrol.h | 54 +++++++ mm/memcontrol.c | 196 +++++++++++++++++++++++- mm/zswap.c | 37 ++++- 4 files changed, 293 insertions(+), 15 deletions(-)