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 X-Spam-Level: X-Spam-Status: No, score=-12.0 required=3.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED,DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A0A74C43461 for ; Fri, 9 Apr 2021 11:04:27 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2E57F610D1 for ; Fri, 9 Apr 2021 11:04:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2E57F610D1 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id B7BCD6B006C; Fri, 9 Apr 2021 07:04:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B53046B006E; Fri, 9 Apr 2021 07:04:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9F3FD6B0070; Fri, 9 Apr 2021 07:04:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0248.hostedemail.com [216.40.44.248]) by kanga.kvack.org (Postfix) with ESMTP id 841746B006C for ; Fri, 9 Apr 2021 07:04:26 -0400 (EDT) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 442ED8248047 for ; Fri, 9 Apr 2021 11:04:26 +0000 (UTC) X-FDA: 78012544932.14.6794D9F Received: from mail-ej1-f53.google.com (mail-ej1-f53.google.com [209.85.218.53]) by imf17.hostedemail.com (Postfix) with ESMTP id 253EA40002DE for ; Fri, 9 Apr 2021 11:04:24 +0000 (UTC) Received: by mail-ej1-f53.google.com with SMTP id e14so7972439ejz.11 for ; Fri, 09 Apr 2021 04:04:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=6/JnVL8LfaZdf+zS+mi0dG+OAyirzCOEuyoJgncWbSg=; b=eq8YU0RewVVk6hub1QGwAdPgMqo88js1FBgRgBvcQ/eyJXx0rrjkdsaRgSy5pVxDE5 FXsGdJBjo1fLI6eyOd3do+o2BR/+B3lrN+9YF5JdxnHBnxtG6YVixgPtvcI4g6BE/yXf S85SCuoabIEhcs2ffoOr5WM62pto6LIZwZI68HCFe7p5hCgbWP21ZowiiUwys/YqUfd+ EfIKV9vaNj4zLYF/uaalUeXtGwXK9HSqWKfzFIH3MNGRv7QlTbwYsr0ita6/SgygEcYf LYKzMGuTsm7MxtLoM5KvLGNVBdxldCOTkFa1SEaxVcmef1vIFgqPsRPp7QowqkI3P6QU Zwbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=6/JnVL8LfaZdf+zS+mi0dG+OAyirzCOEuyoJgncWbSg=; b=CHjPMZqg7LD5rybTWtWLh+EAWweNbk0elWn7PkFDmJ3UJODnF4LGBqvqR3CwgPaSgo pzTAOCCfGZ4NcFVS2BJPtLLAJhyFhXOGPAboVZvjTZ38QcEgGHzzSW+drxnh5dssVbjg WuctqFyxgPHodHGwtNaeMkhMPcPhJIyR/3SJwnRfeCU+vUrgXj18gQYUUOCHjnodeb1B fwNsPvuDh0GjCEEq7jkXrbFc+ei+o3WCEkdYK9kZkJcv7FwcX0ayynaY5mnoOu1mUH8l 9RkcqTsMjkl+OfajuHI7DKs9ZHr9ZhGUzaKA5tSNg0SuiDTYjLPQ+20mjDRD8Kj2oU5/ fjmg== X-Gm-Message-State: AOAM531gkeIZ7KTgGjwbu+y4lTo96Gpp99ko3e4wHnc9GMWmDbz0y82D /mQVkrd9G2jLn5E4rGAEKJ0w6NP7h1Q= X-Google-Smtp-Source: ABdhPJxJNZboaileCS232D/njgL/jwYVi3sL0vyTBT+hTXCmnyaKNCqta3CREGAvoYmQHy0jdYHNYg== X-Received: by 2002:a17:906:7d02:: with SMTP id u2mr129361ejo.249.1617966264746; Fri, 09 Apr 2021 04:04:24 -0700 (PDT) Received: from ?IPv6:2a02:908:1252:fb60:ffef:9b69:ce50:8284? ([2a02:908:1252:fb60:ffef:9b69:ce50:8284]) by smtp.gmail.com with ESMTPSA id e15sm1066012ejh.56.2021.04.09.04.04.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 09 Apr 2021 04:04:24 -0700 (PDT) Subject: Re: [PATCH 1/2] mm/vmscan: add sync_shrinkers function To: Vlastimil Babka , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Cc: ray.huang@amd.com, daniel@ffwll.ch, akpm@linux-foundation.org References: <20210409071725.1532-1-christian.koenig@amd.com> <462c2a51-4aa8-47ba-1c67-171ca651b016@suse.cz> From: =?UTF-8?Q?Christian_K=c3=b6nig?= Message-ID: <951bf630-35e4-9b5a-2ace-007a685d1994@gmail.com> Date: Fri, 9 Apr 2021 13:04:22 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <462c2a51-4aa8-47ba-1c67-171ca651b016@suse.cz> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 253EA40002DE X-Stat-Signature: f4njm6q1yy6xq4fx8pyzmyf4xm4ffwhh Received-SPF: none (gmail.com>: No applicable sender policy available) receiver=imf17; identity=mailfrom; envelope-from=""; helo=mail-ej1-f53.google.com; client-ip=209.85.218.53 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1617966264-386751 Content-Transfer-Encoding: quoted-printable 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: Am 09.04.21 um 13:00 schrieb Vlastimil Babka: > On 4/9/21 9:17 AM, Christian K=C3=B6nig wrote: >> To be able to switch to a spinlock and reduce lock contention in the T= TM >> shrinker we don't want to hold a mutex while unmapping and freeing pag= es >> from the pool. > Does using spinlock instead of mutex really reduce lock contention? Well using the spinlock instead of the mutex is only the cherry on the ca= ke. The real improvement for the contention is the fact that we just grab=20 the next pool and drop the lock again instead of doing the whole IOMMU=20 unmap and flushing of the CPU TLB dance while holding the lock. >> But then we somehow need to prevent a race between (for example) the s= hrinker >> trying to free pages and hotplug trying to remove the device which tho= se pages >> belong to. >> >> Taking and releasing the shrinker semaphore on the write side after >> unmapping and freeing all pages should make sure that no shrinker is r= unning in >> paralell any more. > So you explain this in this commit log for adding the function, but the= n the > next patch just adds a sync_shrinkers() call without any comment. I wou= ld expect > there a comment explaining why it's done there - what it protects again= st, as > it's not an obvious pattern IMHO. Good point, going to add a comment. Thanks, Christian. > >> Signed-off-by: Christian K=C3=B6nig >> --- >> include/linux/shrinker.h | 1 + >> mm/vmscan.c | 10 ++++++++++ >> 2 files changed, 11 insertions(+) >> >> diff --git a/include/linux/shrinker.h b/include/linux/shrinker.h >> index 0f80123650e2..6b75dc372fce 100644 >> --- a/include/linux/shrinker.h >> +++ b/include/linux/shrinker.h >> @@ -92,4 +92,5 @@ extern void register_shrinker_prepared(struct shrink= er *shrinker); >> extern int register_shrinker(struct shrinker *shrinker); >> extern void unregister_shrinker(struct shrinker *shrinker); >> extern void free_prealloced_shrinker(struct shrinker *shrinker); >> +extern void sync_shrinkers(void); >> #endif >> diff --git a/mm/vmscan.c b/mm/vmscan.c >> index 562e87cbd7a1..46cd9c215d73 100644 >> --- a/mm/vmscan.c >> +++ b/mm/vmscan.c >> @@ -408,6 +408,16 @@ void unregister_shrinker(struct shrinker *shrinke= r) >> } >> EXPORT_SYMBOL(unregister_shrinker); >> =20 >> +/** >> + * sync_shrinker - Wait for all running shrinkers to complete. >> + */ >> +void sync_shrinkers(void) >> +{ >> + down_write(&shrinker_rwsem); >> + up_write(&shrinker_rwsem); >> +} >> +EXPORT_SYMBOL(sync_shrinkers); >> + >> #define SHRINK_BATCH 128 >> =20 >> static unsigned long do_shrink_slab(struct shrink_control *shrinkctl= , >>