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 3AFF9C433EF for ; Wed, 27 Apr 2022 01:23:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B561D6B0073; Tue, 26 Apr 2022 21:23:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id ADE026B0075; Tue, 26 Apr 2022 21:23:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 957A86B0078; Tue, 26 Apr 2022 21:23:07 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.27]) by kanga.kvack.org (Postfix) with ESMTP id 7EF6A6B0073 for ; Tue, 26 Apr 2022 21:23:07 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 4629C213DD for ; Wed, 27 Apr 2022 01:23:07 +0000 (UTC) X-FDA: 79400910414.23.229D655 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf03.hostedemail.com (Postfix) with ESMTP id 1BFD220043 for ; Wed, 27 Apr 2022 01:23:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1651022586; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=DpEof+0I0YCbwzONPoRmg0L/6pzi31MyKL13TiqlQ/U=; b=DaCnO4Qx92gXVhIkbQpfz6DsLh8OFU8bg3/d49V8noswSTEiHKwsHCouf2/b9eXlMIrl2M pDwlEaKgLaubWsh7izHWtvDFnZAJAy9P4pvZa5CvXATZ6okWipSAjJjfwUI3oDvwxKxwfK 9ZojhN+ac9OK3bXRtqk9gSyasEc/fpY= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-318-8Qyok9UXPvellTR8YIOXJA-1; Tue, 26 Apr 2022 21:23:01 -0400 X-MC-Unique: 8Qyok9UXPvellTR8YIOXJA-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 40CFA3802AC4; Wed, 27 Apr 2022 01:23:01 +0000 (UTC) Received: from rh (vpn2-54-103.bne.redhat.com [10.64.54.103]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 9C30BC28100; Wed, 27 Apr 2022 01:23:00 +0000 (UTC) Received: from localhost ([::1] helo=rh) by rh with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1njWOP-006YJ1-Jy; Wed, 27 Apr 2022 11:22:57 +1000 Date: Wed, 27 Apr 2022 11:22:55 +1000 From: Dave Chinner To: Roman Gushchin Cc: Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Yang Shi , Kent Overstreet , Hillf Danton Subject: Re: [PATCH v2 0/7] mm: introduce shrinker debugfs interface Message-ID: References: <20220422202644.799732-1-roman.gushchin@linux.dev> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 2.85 on 10.11.54.8 X-Stat-Signature: 1m5ftxrb7nyhzxstqzgnt94d9jkm96hm X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 1BFD220043 Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=DaCnO4Qx; spf=none (imf03.hostedemail.com: domain of dchinner@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=dchinner@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Rspam-User: X-HE-Tag: 1651022582-447133 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: On Tue, Apr 26, 2022 at 09:41:34AM -0700, Roman Gushchin wrote: > Can you, please, summarize your position, because it's a bit unclear. > You made a lot of good points about some details (e.g. shrinkers naming, > and I totally agree there; machines with hundreds of nodes etc), then > you said the active scanning is useless and then said the whole thing > is useless and we're fine with what we have regarding shrinkers debugging. Better introspection the first thing we need. Work on improving that. I've been making suggestions to help improve introspection infrastructure. Before anything else, we need to improve introspection so we can gain better insight into the problems we have. Once we understand the problems better and have evidence to back up where the problems lie and we have a plan to solve them, then we can talk about whether we need other user accessible shrinker APIs. For the moment, exposing shrinker control interfaces to userspace could potentially be very bad because it exposes internal architectural and implementation details to a user API. Just because it is in /sys/kernel/debug it doesn't mean applications won't start to use it and build dependencies on it. That doesn't mean I'm opposed to exposing a shrinker control mechanism to debugfs - I'm still on the fence on that one. However, I definitely think that an API that directly exposes the internal implementation to userspace is the wrong way to go about this. Fine grained shrinker control is not necessary to improve shrinker introspection and OOM debugging capability, so if you want/need control interfaces then I think you should separate those out into a separate line of development where it doesn't derail the discussion on how to improve shrinker/OOM introspection. -Dave. -- Dave Chinner dchinner@redhat.com