On 02.12.2020 21:27, Yang Shi wrote:
> Use per memcg's nr_deferred for memcg aware shrinkers.  The shrinker's 
> nr_deferred
> will be used in the following cases:
>     1. Non memcg aware shrinkers
>     2. !CONFIG_MEMCG
>     3. memcg is disabled by boot parameter
> 
> Signed-off-by: Yang Shi <[email protected]>
> ---
>  mm/vmscan.c | 88 +++++++++++++++++++++++++++++++++++++++++++++++++----
>  1 file changed, 82 insertions(+), 6 deletions(-)
> 
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index cba0bc8d4661..d569fdcaba79 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -203,6 +203,12 @@ static DECLARE_RWSEM(shrinker_rwsem);
>  static DEFINE_IDR(shrinker_idr);
>  static int shrinker_nr_max;
>  
> +static inline bool is_deferred_memcg_aware(struct shrinker *shrinker)
> +{
> +     return (shrinker->flags & SHRINKER_MEMCG_AWARE) &&
> +             !mem_cgroup_disabled();
> +}
> +
>  static int prealloc_memcg_shrinker(struct shrinker *shrinker)
>  {
>       int id, ret = -ENOMEM;
> @@ -271,7 +277,58 @@ static bool writeback_throttling_sane(struct 
> scan_control *sc)
>  #endif
>       return false;
>  }
> +
> +static inline long count_nr_deferred(struct shrinker *shrinker,
> +                                  struct shrink_control *sc)
> +{
> +     bool per_memcg_deferred = is_deferred_memcg_aware(shrinker) && 
> sc->memcg;
> +     struct memcg_shrinker_deferred *deferred;
> +     struct mem_cgroup *memcg = sc->memcg;
> +     int nid = sc->nid;
> +     int id = shrinker->id;
> +     long nr;
> +
> +     if (!(shrinker->flags & SHRINKER_NUMA_AWARE))
> +             nid = 0;
> +
> +     if (per_memcg_deferred) {
> +             deferred = 
> rcu_dereference_protected(memcg->nodeinfo[nid]->shrinker_deferred,
> +                                                  true);

My comment is about both 5/9 and 6/9 patches.

shrink_slab_memcg() races with mem_cgroup_css_online(). A visibility of 
CSS_ONLINE flag
in shrink_slab_memcg()->mem_cgroup_online() does not guarantee that you will see
memcg->nodeinfo[nid]->shrinker_deferred != NULL in count_nr_deferred(). This 
may occur
because of processor reordering on !x86 (there is no a common lock or memory 
barriers).

Regarding to shrinker_map this is not a problem due to map check in 
shrink_slab_memcg().
The map can't be NULL there.

Regarding to shrinker_deferred you should prove either this is not a problem 
too,
or to add proper synchronization (maybe, based on barriers) or to add some 
similar check
(maybe, in shrink_slab_memcg() too).

Kirill

Reply via email to