From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 76AA2C4345F for ; Sat, 13 Apr 2024 05:20:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A20CE6B0087; Sat, 13 Apr 2024 01:19:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9D1BA6B0089; Sat, 13 Apr 2024 01:19:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8715A6B008A; Sat, 13 Apr 2024 01:19:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 689196B0087 for ; Sat, 13 Apr 2024 01:19:59 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 08175A11F1 for ; Sat, 13 Apr 2024 05:19:59 +0000 (UTC) X-FDA: 82003356918.26.A63898D Received: from mail-vk1-f169.google.com (mail-vk1-f169.google.com [209.85.221.169]) by imf10.hostedemail.com (Postfix) with ESMTP id 3EC2BC0005 for ; Sat, 13 Apr 2024 05:19:57 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=j+x2Oens; spf=pass (imf10.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.169 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1712985597; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Z033l8aBmpmazijIqdn4X3dK8gfkoX6WQoDM/KTSRrM=; b=kHSC3m8rIR8J9rWZwkhkAR11oAJObhv/0zS5+djUEN1HVJomw9IBrES+r8Pun4gi+/NjXj 3GlhNFY0ZyfqNC2Flp4aRuM6zxTvnQBMNIM36Aswh4qA3/2RYHN0A1mF+JFnr2b9ulsG05 J5051FucemYRRRRQ0vOJUWMZLnSkisY= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=j+x2Oens; spf=pass (imf10.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.169 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1712985597; a=rsa-sha256; cv=none; b=NW2T24HSgV3qM5DGeafChCy+FyfU/ixwa3ysw4VRyqUcZzas61w4c9Fvej1Yybi8W5YKEr zTVKwkFuCSf/pukvJfA/JRUpNo4VozEvyZfDd4XENIjiPvUa5wDA2smplyhDpFsPXN6+2U pa/hyTZmI6o/7k0/8Z5PJMgodayDWVQ= Received: by mail-vk1-f169.google.com with SMTP id 71dfb90a1353d-4dabc6f141bso524533e0c.2 for ; Fri, 12 Apr 2024 22:19:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712985596; x=1713590396; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Z033l8aBmpmazijIqdn4X3dK8gfkoX6WQoDM/KTSRrM=; b=j+x2Oens5hIwfEHwy1d9TTalFS77pQctJtDxk9tlQEqF8kwvarl/9NCXm+kFJdqWbf MjL9pr2pieYF0R3vriQWtLgTgIT3e9zNC0QBuJrw4xNkZBIlyR0eyuDiR/hA07Vvd2uH aUJ7aPnN4u3tkjREl2qPyNaGm3XR9Z4FbvIJp914sD6vMrrOlFwBltMMpNkVjGpZjdck RR2X3XFmqSjDQWh9d0R0r28Q0UpP1WlnaOXjHzAXQn78zFG8ac+cK12Cu1Y0vbKFpcsj ooxSuYuk5OowJl5+tJvU+yGNHiVtACksILJd/vCZGgl2sDYdlKB2iOeevVsYfs3K45jY BpEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712985596; x=1713590396; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Z033l8aBmpmazijIqdn4X3dK8gfkoX6WQoDM/KTSRrM=; b=fucTrmRfmuIn1oVqBqHfYQDbjjFIREaNRYyL6HSsw5GN3hsjVPllKnOCgV4n5qf/1p J9JeeyLq9CNl8LbrcTn74F2nLsmqjHISLvc0ZQrpMPbFIVdAlRPjmqUFPFjQCEYQfA7w w1R3mf3ElQPVfBBSnItP4LWBHMWe3jmIrxbXHEQ0DkERwz8e6m9QQiEgtOx+1XICoqOZ kbo9CDNEhizm0SNBcMxJVWKY1RCTEyPS/VoQUG2H4Bv6lvMC+WwRTPnE+P5GmnE87cm+ cuVjVWs+jnaA+Y3ySlt+uf3o+GAAqFNnx8gXCXmDn9r3NQK/C1xhf4VR7hyFnjp0a0bu Ki+Q== X-Forwarded-Encrypted: i=1; AJvYcCUNdIhWcid8n6KxJesHum0/FBQRsRBOzes5VxHdOmkTsfvMFY6zZBTKZz22f2v+99tEDo3+oKu21b7JTXEeQYQY9oo= X-Gm-Message-State: AOJu0Yx1mP5Vch6zzIm0Y7n/JH4vWU7YNZlSS96AF6oVZxsNSK6bQFdV Zn+wDwjXDBuS926Alb+F5U+6WeHH0EeXdB3/P0KX8cGTtACvGCNh+LsgBE5Uzis0b2vkj1UyGQl m9Jl2AFa8PO6GlYzzquXG3B5lDkk= X-Google-Smtp-Source: AGHT+IGmXMo7rIWI2XQN4+oSlAn7GwLHqPD1oNcVmQbFVLAVgpKcOrn+79N1muwSp3oBCu0MbkXGP0QIxmZEVIopPCk= X-Received: by 2002:a05:6122:c9f:b0:4d3:3a8c:13ad with SMTP id ba31-20020a0561220c9f00b004d33a8c13admr4533302vkb.8.1712985596121; Fri, 12 Apr 2024 22:19:56 -0700 (PDT) MIME-Version: 1.0 References: <20240413015410.30951-1-lipeifeng@oppo.com> In-Reply-To: <20240413015410.30951-1-lipeifeng@oppo.com> From: Barry Song <21cnbao@gmail.com> Date: Sat, 13 Apr 2024 17:19:44 +1200 Message-ID: Subject: Re: [PATCH v2] mm/shrinker: add SHRINKER_NO_DIRECT_RECLAIM To: lipeifeng@oppo.com Cc: akpm@linux-foundation.org, david@fromorbit.com, zhengqi.arch@bytedance.com, roman.gushchin@linux.dev, muchun.song@linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 3EC2BC0005 X-Rspam-User: X-Stat-Signature: ibn9atte8igargnz1m3px4tm8hc9ih8g X-Rspamd-Server: rspam01 X-HE-Tag: 1712985597-115492 X-HE-Meta: U2FsdGVkX19kOvIoA9vjALpY/z4QbFisH+/J7lFyztaV9et88PibW4+IJZDs6k0gW8TXV5CEowDki6+OOfvVXbmIy/5FEp4jQBnR0AnjxxWQQzy3JO8WBvlSoWXAaD+lVEd0dui+VS7X2VQquptbNdlB62UaLMYEaw4E0yU1p701GNrOaC/ABkBUeVxyuX9E5zIjF12mmcQD2ZNUpR/NBDQaskmtejTmhRWq22yzDWG7GDJ8b7kXJQfUthbuyWDfl8l1lLS1C7LN2L4r383VhA4k7Qe6GB5ZwiQySTSbnd+Hwzltzg0bsFy4sVvTR+mJCsgqUEbgZLaQTvP/JQ09jcIgSDvf7A6g0TjjXX/JwRo94wQSWfZwUpW2BrAmHfRg9cD34uRlAMpx4wHQxWY4bQaZelkhkRrFMenBdpUoB4GKf7+9HORJhGMi5vbHqK3cJsDuCPSCFTi3mxvf7nU9sbv8rWsy1UXcwBwnwrmvT0Jcaswk5nm4GvUJv6fkTQHXnynfjGYrEz/DNduwVjwHvg/qk/01qf//AWfARu/l/lJ/D6aOM4qssFZ59cUwRAPBsom6DUiro09oLlg42EHIvaFNX/WtbV45oVxIXe6UwOb6bDsozl4IuP6ebCVuBT7Lwt1Ry/nYr6/Edqjn5xsQ75wh+v8eM7xH0V765fYkfl8QpmpnDDsNK4pZQzY6c5gVYEZdGCzFPnd8vFSXrlK98X8d1hp7hyJTJH/t7vX5MBmqt3wDm7hXmsNjytWRgUsEQY+2JoKxrW3AxiQXgHdWUO77wXPRDq8ZsKgV1vL4Hl/d+tgLI6TjztVHsTnVXCUMcd67LeVgzTyp8ybAFsvwNpg2uYHqpwbebJloRzlnYr+X7Vbdd32aYZ1MQwMHFMnceNlsPFtcLyYLuQ3jMseY07CYstpxoGVe2cerzvzR+eQKf1l2dudj61OnX9z7uBdL7T4Tn/Jo7Ui9AGfnQ/L X1KnglB6 parL+TUGtWE7rFztvr88bFjM594i/+Wf8cN0Wq/r/TeEqaQrUt/0EZUCX0Sjsf8ygnhUKbC+DBgrw4QT10QteiO0ra8MtzgI4oo+BTcZs6PtFI6am9AMvfxmYePLLh6PihOdkXh2ZpPUqruc8EtQf7Mm+FhuEca3sMsqMG0uC2JwiWzDqcvJZQsvX2wyU7hIrsOHc1HvHVvIbuC4DjAIfkdjy93iV+PP6hdzVDit5wO8N+Y9Iprif7/CZ4C1NjevBkpp/GnIiZnzVmC6Euzk4pdtsQxu2zmQgXN1NUKtdkE6LyhPeaAhV8RDv+movbcnJRF+Ctou9pyP8oDrbDTwJaXACcOMEsyDveJreu1jPR8J/a+4SpEm1hqkoYlQdTIdMpdtyLnxXIUGerKCsk3VWdI2SBmKsDu73Xj6DZFwYy+xZoJZL4b8H4WPyI3OprikFFfB1lEIq9MitX1M+KM8xGGCLJBL8ZvADRq4TbALYrWOwl77JhUDQXsvZ3A== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Sat, Apr 13, 2024 at 1:54=E2=80=AFPM wrote: > > From: Peifeng Li > > In the case of insufficient memory, threads will be in direct_reclaim to > reclaim memory, direct_reclaim will call shrink_slab to run sequentially > each shrinker callback. If there is a lock-contention in the shrinker > callback,such as spinlock,mutex_lock and so on, threads may be likely to > be stuck in direct_reclaim for a long time, even if the memfree has reach= ed > the high watermarks of the zone, resulting in poor performance of threads= . > > Example 1: shrinker callback may wait for spinlock > static unsigned long mb_cache_shrink(struct mb_cache *cache, > unsigned long nr_to_scan) > { > struct mb_cache_entry *entry; > unsigned long shrunk =3D 0; > > spin_lock(&cache->c_list_lock); > while (nr_to_scan-- && !list_empty(&cache->c_list)) { > entry =3D list_first_entry(&cache->c_list, > struct mb_cache_entry, e_list); > if (test_bit(MBE_REFERENCED_B, &entry->e_flags) || > atomic_cmpxchg(&entry->e_refcnt, 1, 0) !=3D 1) { > clear_bit(MBE_REFERENCED_B, &entry->e_flags); > list_move_tail(&entry->e_list, &cache->c_list); > continue; > } > list_del_init(&entry->e_list); > cache->c_entry_count--; > spin_unlock(&cache->c_list_lock); > __mb_cache_entry_free(cache, entry); > shrunk++; > cond_resched(); > spin_lock(&cache->c_list_lock); > } > spin_unlock(&cache->c_list_lock); > > return shrunk; > } > Example 2: shrinker callback may wait for mutex lock > static > unsigned long kbase_mem_evictable_reclaim_scan_objects(struct shrinker *s= , > struct shrink_control *sc) > { > struct kbase_context *kctx; > struct kbase_mem_phy_alloc *alloc; > struct kbase_mem_phy_alloc *tmp; > unsigned long freed =3D 0; > > kctx =3D container_of(s, struct kbase_context, reclaim); > > // MTK add to prevent false alarm > lockdep_off(); > > mutex_lock(&kctx->jit_evict_lock); > > list_for_each_entry_safe(alloc, tmp, &kctx->evict_list, evict_nod= e) { > int err; > > err =3D kbase_mem_shrink_gpu_mapping(kctx, alloc->reg, > 0, alloc->nents); > if (err !=3D 0) { > freed =3D -1; > goto out_unlock; > } > > alloc->evicted =3D alloc->nents; > > kbase_free_phy_pages_helper(alloc, alloc->evicted); > freed +=3D alloc->evicted; > list_del_init(&alloc->evict_node); > > kbase_jit_backing_lost(alloc->reg); > > if (freed > sc->nr_to_scan) > break; > } > out_unlock: > mutex_unlock(&kctx->jit_evict_lock); > > // MTK add to prevent false alarm > lockdep_on(); > > return freed; > } > > In mobile-phone,threads are likely to be stuck in shrinker callback durin= g > direct_reclaim, with example like the following: > <...>-2806 [004] ..... 866458.339840: mm_shrink_slab_start: > dynamic_mem_shrink_scan+0x0/0xb8 ... priority 2 > <...>-2806 [004] ..... 866459.339933: mm_shrink_slab_end: > dynamic_mem_shrink_scan+0x0/0xb8 ... > > For the above reason, the patch introduces SHRINKER_NO_DIRECT_RECLAIM tha= t > allows driver to set shrinker callback not to be called in direct_reclaim > unless sc->priority is 0. > > The reason why sc->priority=3D0 allows shrinker callback to be called in > direct_reclaim is for two reasons: > 1.Always call all shrinker callback in drop_slab that priority is 0. > 2.sc->priority is 0 during direct_reclaim, allow direct_reclaim to call > shrinker callback, to reclaim memory timely. > > Note: > 1.shrinker_register() default not to set SHRINKER_NO_DIRECT_RECLAIM, to > maintain the current behavior of the code. > 2.Logic of kswapd and drop_slab to call shrinker callback isn't affected. > > Signed-off-by: Peifeng Li > --- > -v2: fix the commit message > include/linux/shrinker.h | 5 +++++ > mm/shrinker.c | 38 +++++++++++++++++++++++++++++++++++--- > 2 files changed, 40 insertions(+), 3 deletions(-) > > diff --git a/include/linux/shrinker.h b/include/linux/shrinker.h > index 1a00be90d93a..2d5a8b3a720b 100644 > --- a/include/linux/shrinker.h > +++ b/include/linux/shrinker.h > @@ -130,6 +130,11 @@ struct shrinker { > * non-MEMCG_AWARE shrinker should not have this flag set. > */ > #define SHRINKER_NONSLAB BIT(4) > +/* > + * Can shrinker callback be called in direct_relcaim unless > + * sc->priority is 0? > + */ > +#define SHRINKER_NO_DIRECT_RECLAIM BIT(5) > My point is, drivers won't voluntarily stay unreclaimed during direct reclamation. Hence, this approach is unlikely to succeed. Those drivers can't be trusted. Had they been aware of their slowness, they wouldn't have written code in this manner. Detecting problematic driver shrinkers and marking them as skipped might prove challenging. I concur with Zhengqi; the priority should be fixing the driver whose shrinker is slow. Do you have a list of slow drivers? > __printf(2, 3) > struct shrinker *shrinker_alloc(unsigned int flags, const char *fmt, ...= ); > diff --git a/mm/shrinker.c b/mm/shrinker.c > index dc5d2a6fcfc4..7a5dffd166cd 100644 > --- a/mm/shrinker.c > +++ b/mm/shrinker.c > @@ -4,7 +4,7 @@ > #include > #include > #include > - > +#include > #include "internal.h" > > LIST_HEAD(shrinker_list); > @@ -544,7 +544,23 @@ static unsigned long shrink_slab_memcg(gfp_t gfp_mas= k, int nid, > if (!memcg_kmem_online() && > !(shrinker->flags & SHRINKER_NONSLAB)) > continue; > - > + /* > + * SHRINKER_NO_DIRECT_RECLAIM, mean that shrinker= callback > + * should not be called in direct_reclaim unless = priority > + * is 0. > + */ > + if ((shrinker->flags & SHRINKER_NO_DIRECT_RECLAIM= ) && > + !current_is_kswapd()) { > + /* > + * 1.Always call shrinker callback in dro= p_slab that > + * priority is 0. > + * 2.sc->priority is 0 during direct_recl= aim, allow > + * direct_reclaim to call shrinker callba= ck, to reclaim > + * memory timely. > + */ > + if (priority) > + continue; > + } > ret =3D do_shrink_slab(&sc, shrinker, priority); > if (ret =3D=3D SHRINK_EMPTY) { > clear_bit(offset, unit->map); > @@ -658,7 +674,23 @@ unsigned long shrink_slab(gfp_t gfp_mask, int nid, s= truct mem_cgroup *memcg, > continue; > > rcu_read_unlock(); > - > + /* > + * SHRINKER_NO_DIRECT_RECLAIM, mean that shrinker callbac= k > + * should not be called in direct_reclaim unless priority > + * is 0. > + */ > + if ((shrinker->flags & SHRINKER_NO_DIRECT_RECLAIM) && > + !current_is_kswapd()) { > + /* > + * 1.Always call shrinker callback in drop_slab t= hat > + * priority is 0. > + * 2.sc->priority is 0 during direct_reclaim, all= ow > + * direct_reclaim to call shrinker callback, to r= eclaim > + * memory timely. > + */ > + if (priority) > + continue; > + } > ret =3D do_shrink_slab(&sc, shrinker, priority); > if (ret =3D=3D SHRINK_EMPTY) > ret =3D 0; > -- > 2.34.1 Thanks Barry