Received: by 2002:a05:6602:18e:0:0:0:0 with SMTP id m14csp5882806ioo; Wed, 1 Jun 2022 14:56:20 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxABcL2a9rhBolbagtYS11likVM0m8DEs0XHP4hHMXxuyJumdqp3dOT9yb/5jmunebFQg73 X-Received: by 2002:a63:44b:0:b0:3fc:cd1c:49e8 with SMTP id 72-20020a63044b000000b003fccd1c49e8mr1302826pge.172.1654120580676; Wed, 01 Jun 2022 14:56:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1654120580; cv=none; d=google.com; s=arc-20160816; b=svtCLFyjY4LhObMsHwcETLRrYnatAXKaWo4JmJsqK/pTk69QEkp06LJ0Gnyql8KfSm qIqgkR5dmugv+7hXgA5XQDM05qDzR6A0z9RwOqat94pJZCvTEj9F1o1WFvFYurHs9twn kKqFJnqg3I1Vyvh81xx88CPRPnVMTPfRuiaYZObkVYYE3blZtFivzPLmXHeE8hd4jrL7 J2QdPsU5QSa5ing30H5cZvI/ZuQ6uNuo67WpBmVV65U0wEhv2iDZxWmMzze0a7uldLfv qfXM3Uo2T8MCT3QiXZ8PsZUIyTHKHRA/B5cr1bYNvyVHguE5reVAOsMa11U8Lzh/cTXh uzaQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=HCIvyQAL4yUlVAgmmgnCXhAQEOkBIcT0ld8kJhRhm98=; b=PwkGxkIh8ACp6h4JCKQLsf4hti3pZgExiy+bHWrMfBOMLG2Ex3FoRJ507Q5cB5wxC2 K8ax5v38CGNd9v79R7hBvdiYgdfAb7FZnpLoyQtb5S7BJMbgYTxiqGOGAScsQwdxGoZi PCGsSQXcfT7wI4rCtsvFAIvOdGhKZUjFXqcdpBC++eaY7qTNxJX22kE9THo75YtqdLa+ rzMTVUAe5RcBDXoNeTXtKI0MeWuCIaZd4W6v4U/T4LCZkGVW3wUfNI0xO3slOKm0zGZm VwkRQQQjulqMDv44PAObtNMHznfYOVt5GA0RNNmPbksYGBSIHT9Dd2gdHaHzV74RUaUH xfeA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=korg header.b=S1JHdwp5; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id u18-20020a17090341d200b001587f099641si1230250ple.387.2022.06.01.14.56.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Jun 2022 14:56:20 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=korg header.b=S1JHdwp5; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 6A77811E1D8; Wed, 1 Jun 2022 14:24:15 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231529AbiFAVYD (ORCPT + 99 others); Wed, 1 Jun 2022 17:24:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39814 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231539AbiFAVX4 (ORCPT ); Wed, 1 Jun 2022 17:23:56 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 19B47121CD3 for ; Wed, 1 Jun 2022 14:23:54 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id A97886137F for ; Wed, 1 Jun 2022 21:23:53 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C5328C385B8; Wed, 1 Jun 2022 21:23:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1654118633; bh=baI/1cZI79/wp6OfnaSzJG6jkPfaG7SAvX2xPJStV0U=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=S1JHdwp5rwuGpJRGBvPvtFKqIeTSaxNjhiQeKUhjBQ0l9XOrcbEdVMcGFelZSB8fr bR2+KBh0DUkUOw0zdTKPklwQvNK116WN2NT3TDNQCOPaQ6uNNkUNE8AuPddKmzkpu2 mlqDg99/N3K5r6hozbYudcjal27ZOi/rQWoSg1xI= Date: Wed, 1 Jun 2022 14:23:51 -0700 From: Andrew Morton To: Roman Gushchin Cc: linux-mm@kvack.org, Dave Chinner , linux-kernel@vger.kernel.org, Kent Overstreet , Hillf Danton , Christophe JAILLET , Muchun Song Subject: Re: [PATCH v5 6/6] mm: shrinkers: add scan interface for shrinker debugfs Message-Id: <20220601142351.5e04fea5586ca51898d8785f@linux-foundation.org> In-Reply-To: <20220601032227.4076670-7-roman.gushchin@linux.dev> References: <20220601032227.4076670-1-roman.gushchin@linux.dev> <20220601032227.4076670-7-roman.gushchin@linux.dev> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,RDNS_NONE,SPF_HELO_NONE, T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 31 May 2022 20:22:27 -0700 Roman Gushchin wrote: > Add a scan interface which allows to trigger scanning of a particular > shrinker and specify memcg and numa node. It's useful for testing, > debugging and profiling of a specific scan_objects() callback. > Unlike alternatives (creating a real memory pressure and dropping > caches via /proc/sys/vm/drop_caches) this interface allows to interact > with only one shrinker at once. Also, if a shrinker is misreporting > the number of objects (as some do), it doesn't affect scanning. > > .. > > --- a/mm/shrinker_debug.c > +++ b/mm/shrinker_debug.c > @@ -99,6 +99,78 @@ static int shrinker_debugfs_count_show(struct seq_file *m, void *v) > } > DEFINE_SHOW_ATTRIBUTE(shrinker_debugfs_count); > > +static int shrinker_debugfs_scan_open(struct inode *inode, struct file *file) > +{ > + file->private_data = inode->i_private; > + return nonseekable_open(inode, file); > +} > + > +static ssize_t shrinker_debugfs_scan_write(struct file *file, > + const char __user *buf, > + size_t size, loff_t *pos) > +{ > + struct shrinker *shrinker = file->private_data; > + unsigned long nr_to_scan = 0, ino; > + struct shrink_control sc = { > + .gfp_mask = GFP_KERNEL, > + }; > + struct mem_cgroup *memcg = NULL; > + int nid; > + char kbuf[72]; > + int read_len = size < (sizeof(kbuf) - 1) ? size : (sizeof(kbuf) - 1); size_t or ulong would be more appropriate. > + ssize_t ret; > + > + if (copy_from_user(kbuf, buf, read_len)) > + return -EFAULT; > + kbuf[read_len] = '\0'; > + > + if (sscanf(kbuf, "%lu %d %lu", &ino, &nid, &nr_to_scan) < 2) Was it intentional to permit more than three args? > + return -EINVAL; > + > + if (nid < 0 || nid >= nr_node_ids) > + return -EINVAL; > + > + if (nr_to_scan == 0) > + return size; > + > + if (shrinker->flags & SHRINKER_MEMCG_AWARE) { > + memcg = mem_cgroup_get_from_ino(ino); > + if (!memcg || IS_ERR(memcg)) > + return -ENOENT; > + > + if (!mem_cgroup_online(memcg)) { > + mem_cgroup_put(memcg); > + return -ENOENT; > + } > + } else if (ino != 0) { > + return -EINVAL; > + } > + > + ret = down_read_killable(&shrinker_rwsem); > + if (ret) { > + mem_cgroup_put(memcg); > + return ret; > + } > + > + sc.nid = nid; > + sc.memcg = memcg; > + sc.nr_to_scan = nr_to_scan; > + sc.nr_scanned = nr_to_scan; > + > + shrinker->scan_objects(shrinker, &sc); > + > + up_read(&shrinker_rwsem); > + mem_cgroup_put(memcg); > + > + return size; > +}