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 CE806C6FD18 for ; Wed, 29 Mar 2023 06:04:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 302626B0072; Wed, 29 Mar 2023 02:04:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 28D1C6B0074; Wed, 29 Mar 2023 02:04:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 12D186B0075; Wed, 29 Mar 2023 02:04:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id F33306B0072 for ; Wed, 29 Mar 2023 02:04:29 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 95985AC0D4 for ; Wed, 29 Mar 2023 06:04:29 +0000 (UTC) X-FDA: 80620896258.07.94C2211 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) by imf11.hostedemail.com (Postfix) with ESMTP id 750B940014 for ; Wed, 29 Mar 2023 06:04:27 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b="K/J8IBFH"; spf=none (imf11.hostedemail.com: domain of mcgrof@infradead.org has no SPF policy when checking 198.137.202.133) smtp.mailfrom=mcgrof@infradead.org; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=kernel.org (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1680069867; h=from:from:sender: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=aNAy4SkGOGqn/8SCjHiEfeWwyWn89H5Tz+V43gHoZjQ=; b=3Qm4oFQGQKn1JCVFTYZnPaCQq9vDGEXC+WeLxQBuGpCMNUKRgRMUa4dNiDPHjVusWI2+kQ Pog2b1sCX/ElTCLyIMIaHSF1kqViS4D1Gvwgs71wTp5wQbX6FEfx7gpw2f6En94q0yzF2w MoHaiR+N41Oj5c35ziVuHRzJ+1k6W5s= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b="K/J8IBFH"; spf=none (imf11.hostedemail.com: domain of mcgrof@infradead.org has no SPF policy when checking 198.137.202.133) smtp.mailfrom=mcgrof@infradead.org; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=kernel.org (policy=none) ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1680069867; a=rsa-sha256; cv=none; b=vWb9zLrF7fLUFZ3RUakwShwHXQZyyT0yuHbk8h6fwLwQRobs3/SZrfgOR0oXhr3sPv3jKN y+VhyvrNRE8Maw/qz8oS/FUXC3unGdwgF0x0ej2qSm0wvunRllwoy/UiSCmNpB8OnmgOY+ E9zW5wfCU2PWG4bGYybAW5pVgm8DtU4= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=aNAy4SkGOGqn/8SCjHiEfeWwyWn89H5Tz+V43gHoZjQ=; b=K/J8IBFH1dwSafahsbzjA5DGva /WZmU+2EOfztohNxfTV71mSWZwFUEPQWarWp1I4Y9h1bgQHBzZocxyKsMbTu0Rr15rE4BzusazLNL ulo/wxJNdrBjYuA5U1G71HRfHCYTugoMIheTjiMlXaYm4QsXjH0yu0CCsqZJsI3m48M/S/z5Ik7ix eCv2yDWywLtzXWLpXXtcBCk71/CkOER1OVgbFISpnKUJ8WG3o1SVTmXUATBKJy8nIVAurxCWVz9hL QGVlnAr6SUc/+wxr/hD3pMsXNL73PVuFH4hpF0xVi/69wdsrmLPeUgOJLZB3XXHQvxllAbTqti8+8 X7llhk1A==; Received: from mcgrof by bombadil.infradead.org with local (Exim 4.96 #2 (Red Hat Linux)) id 1phOuz-00Glg9-0h; Wed, 29 Mar 2023 06:04:21 +0000 Date: Tue, 28 Mar 2023 23:04:21 -0700 From: Luis Chamberlain To: Greg KH Cc: david@redhat.com, patches@lists.linux.dev, linux-modules@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, pmladek@suse.com, petr.pavlu@suse.com, prarit@redhat.com, torvalds@linux-foundation.org, rafael@kernel.org, christophe.leroy@csgroup.eu, tglx@linutronix.de, peterz@infradead.org, song@kernel.org, rppt@kernel.org, willy@infradead.org, vbabka@suse.cz, mhocko@suse.com, dave.hansen@linux.intel.com Subject: Re: [PATCH 7/7] module: add debug stats to help identify memory pressure Message-ID: References: <20230329053149.3976378-1-mcgrof@kernel.org> <20230329053149.3976378-8-mcgrof@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: cokn8y9z65h7po7bneruwubpbdcmtnsi X-Rspam-User: X-Rspamd-Queue-Id: 750B940014 X-Rspamd-Server: rspam06 X-HE-Tag: 1680069867-159359 X-HE-Meta: U2FsdGVkX182ajYG6CfkNByY4ONui2F/uCn+T1KwPhsmHx17QmuYRog/uYW6f6tXLnbOcCAULJ28VVxuPliGEXdKXdBhApPmQYKb8HEnbxW0sijHeIeEj5J4jfZ1lZ7WUpsUHadQj+LH3i8tLyM2qbubMCT353IZQoj5jRFKz8PwuanIa0XoIaQAj1BSaE2PwiwxSng9DPje1eq/XSiJdgdYueeR5ZOV/edk49scOqiprf4B8PTDhQS8qeYnHzvXSMEzRHmwzUuJyfVqcD2SNs/wLXsbeFxgJxRqgop1fcXBbmUu3K5A1wwRoELv8IcDDJEVVwlTM5mvJzq84fJ7CHT9pN2ZmfZ7PSfLevC9lH6m6nkN5Q7jhoApubyinBhZe+ZytMbmIuWviRb2jxiRmWIyfGXM+n8lwmJs+dQG/aiXq8UBBjbn7j/VPQ6uYDPjmdpi9cesrRRvGuJwyFxefbsMeNkgxOo5MgPyPGy/fHyCZMxglbqlY+GunSpTDL6HvB4hkg/0hdbvVR98YzAL3EN+Oo5/bjdp6J+p6+Q/2IgLsYr1FrbiTzztAIKabPzzmtVYM4r9rN/ecylnMMKBFoyDSZcO/jrA1R7OXA5bgzjn9QNzS6KcjZp0tXkPhGtM0XnnKuex6BchjRl/6EyPos7UKSqKzrl6bH8Z+q0e9+JGJUrA4OSEhT5/tM0fW3lR7Ge2YYTSbkXH9MsqOA8ug43OY/gqi5Rpf0fqKtvuKooWazfYD4yZIF8hpHXQ5AvDoNItOwOW+jSRhISlf0HrtK9TRpj4Sw/iK17319cVNJHEpTEGjkFLtGJYQ9K85pmZ9zZvBSnnkViCeyfPG3FSfdRYaY9kwn99rOuDC0yJfRxDw+/WkJl9EFnvtYeGRxE9M4UyUvlOdslleuQnpWy2+mWRaaY78PQj7uKKK0H+7RbbjWJbw8pGDaZ7NtD0CZ8TAqIob8LR6bjUGTaDB9b UUf/2oM8 TBri3R/ghSZ7+FKa7gEVg2frFcGgcZ3/KaQnXnAx9IPrF6RrxF9PYtYJe6RrLmcGEYkSMAxlpJQbapiWnsWr1F2QKr3LV4KgEa+2TH0vMD0/Frv0QJSDvMlZjimVnlRaUd5Wm1hI/aBTfloJJZNk5HB7Lep94f3+xVysqASwnK/P6M1TXAidXTJi8gfKIQKCzDyPTrfxqXdE3lj1vKg3NtQ6upxv0Nk6lQI68LCieEpu5dfeWJEZj3bDjIFDjTPwXPsNPdrMXgxbbcKRjCZqkPiKByGufGrMDINLrXNStgg35ZteJ8xmp/i9uVocsKtaRoxqPIWvdSJed/so= 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 Wed, Mar 29, 2023 at 07:46:22AM +0200, Greg KH wrote: > On Tue, Mar 28, 2023 at 10:31:49PM -0700, Luis Chamberlain wrote: > > Loading modules with finit_module() can end up using vmalloc(), vmap() > > and vmalloc() again, for a total of up to 3 separate allocations in the > > worse case for a single module. We always kernel_read*() the module, > > that's a vmalloc(). Then vmap() is used for the module decompression, > > and if so the last read buffer is freed as we use the now decompressed > > module buffer to stuff data into our copy module. The last one is > > specific to architectures but pretty much that's generally a series > > of vmalloc() for different ELF sections... > > > > Evaluation with new stress-ng module support [1] with just 100 ops > > us proving that you can end up using GiBs of data easily even if > > we are trying to be very careful not to load modules which are already > > loaded. 100 ops seems to resemble the sort of pressure a system with > > about 400 CPUs can create on modules. Although those issues for so > > many concurrent loads per CPU is silly and are being fixed, we lack > > proper tooling to help diagnose easily what happened, when it happened > > and what likely are the culprits -- userspace or kernel module > > autoloading. > > > > Provide an initial set of stats for debugfs which let us easily scrape > > post-boot information about failed loads. This sort of information can > > be used on production worklaods to try to optimize *avoiding* redundant > > memory pressure using finit_module(). > > > > Screen shot: > > > > root@kmod ~ # cat /sys/kernel/debug/modules/stats > > Modules loaded 67 > > Is this "loaded now", or "ever successfully loaded"? As in a > modprobe/rmmod/modprobe would bump this by 2, right? Ah, the later, so "how modules have I ever loaded". Maybe Modules ever loaded ? Will fix the nits, thanks! > > diff --git a/kernel/module/debug.c b/kernel/module/debug.c > > Why is this a whole separate file? It's just a style preference, no real hard reason other than module.c was huge before and now its split up. I find that easier to review / manage. Certainly overkill for such as simple thing but if its debug I think I rather see that then some ifdef eyesore. But that's just preference. > And as MODULE_DEBUG does not reference debugfs, That should be fixed thanks. > > diff --git a/kernel/module/internal.h b/kernel/module/internal.h > > index 6ae29bb8836f..a645cb3fafc7 100644 > > --- a/kernel/module/internal.h > > +++ b/kernel/module/internal.h > > @@ -143,6 +143,41 @@ static inline bool set_livepatch_module(struct module *mod) > > #endif > > } > > > > +#ifdef CONFIG_MODULE_STATS > > + > > +#define mod_stat_add64(count, var) atomic64_add(count, var) > > +#define mod_stat_inc(name) atomic_inc(name) > > Ok, but: > > > +#define mod_stat_inc(name) atomic_inc(name) > > Why do you still increment the variable here if the option is not > enabled? Whoops, will fix! > Also, didn't we have some sort of "we want to use an atomic variable as > statistics" type somewhere in the kernel? I didn't get the memo, nor do I recall, so it's not on my radar. > Or did that never get accepted? Not sure. > And do all of these really need to be atomic variables? Don't you have > locks for some of this to not need the atomic-ness of them? I guess it > doesn't matter much as this isn't that fast of a code-path. That was actually intentional, as this only *grows* I just care its not 0 so to help divide by the total number of modules to get average module length and average module .text length. I used atomics and made it only grow precisely to not have to lock anywhere. Luis