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 36F27CEBF7D for ; Fri, 27 Sep 2024 07:28:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B07F96B00B1; Fri, 27 Sep 2024 03:28:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AB8016B00B2; Fri, 27 Sep 2024 03:28:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 958466B00B3; Fri, 27 Sep 2024 03:28:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 760226B00B1 for ; Fri, 27 Sep 2024 03:28:36 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 02ECAA0830 for ; Fri, 27 Sep 2024 07:28:35 +0000 (UTC) X-FDA: 82609690632.22.B7C5DF0 Received: from mail-lf1-f47.google.com (mail-lf1-f47.google.com [209.85.167.47]) by imf11.hostedemail.com (Postfix) with ESMTP id 2758440007 for ; Fri, 27 Sep 2024 07:28:33 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=T2IrakLg; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf11.hostedemail.com: domain of fangzheng.zhang1003@gmail.com designates 209.85.167.47 as permitted sender) smtp.mailfrom=fangzheng.zhang1003@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727422077; a=rsa-sha256; cv=none; b=srBhFBSJPuAOermjOlDBGQLsAqw4dYWXC2Za/KZmsyXZsa7deRS/oENxkLWpXI2JZEJq+6 TTYmCxT7veYngTATA1PhetJLYvv8+d4hYvsVDdFuCFSQ8xyRAFH+ay9NKoeWmJAPfE4qJr x9afaa/SzLJs4KcP9WmCNoYqfz+IW0w= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=T2IrakLg; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf11.hostedemail.com: domain of fangzheng.zhang1003@gmail.com designates 209.85.167.47 as permitted sender) smtp.mailfrom=fangzheng.zhang1003@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727422077; 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=uoJ3Ph451WRu4/35p1hS+4je1NRBdhgvP4Y7yp3yAGY=; b=kFq9wqE1lvlVXagI6Z3Nc9GHr45krkBJv2r/LiBQcrUDI/iAvtEkl2y94qbZ2Xozgr+C0+ Q3IvaIpkdRjjRcw/600Eb5NDx97UrtetASUN6SzMVYM6xZprrUmWqIo0AZ1FoZDAzsrHSZ PGBFmK336w/pCHzg0TzpET322+ZvQiQ= Received: by mail-lf1-f47.google.com with SMTP id 2adb3069b0e04-539885dd4bcso368285e87.0 for ; Fri, 27 Sep 2024 00:28:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1727422112; x=1728026912; 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=uoJ3Ph451WRu4/35p1hS+4je1NRBdhgvP4Y7yp3yAGY=; b=T2IrakLg/u9ABsPGEzqb5qP9OCWiL4ZHyTwjrcfJZDlC26NfGNEFAAmLSZjlippxU0 UrkXnLaUjmfnMizREI3UvP3L34JUd5rRVUdg9wJGoqcvx6W3oCCA0Z+l4b/l52zjNYa8 aSePAA1iYm2CXyIve/2upu/xy9Pmc52KOg9TPE5EoJlaNDNS4DwA1hQvKar80PtOuQcf W2lXYu1qbua78eHliCHkXMo2BOILV+SvF8415oC11010fBSVDQLRzuJ+kc7KsrXaH03p dftTCRlhgc1bjG5UlTpNRaBo/Hd+ZeX85b0IAbEKR7nNlnb2Uf5OiOQZSgmYH1oTDww9 R4sA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727422112; x=1728026912; 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=uoJ3Ph451WRu4/35p1hS+4je1NRBdhgvP4Y7yp3yAGY=; b=HelKRxI6N94DixN0/JEFIoYmm5JLd0glszmjkUHDY4VXZV4y8FWooq1/NGI0WtdSFY tds/CvuMYRMG+7EFVFYwMLUklH3IlTTUOdBg75gl0Ky4aQUp1PChRfcFLsQC8yzWE8/d 4+Bhx1hYb7o6C03ZjzXAQUJRYnRqT8YxqzibsLNj7ZWVTpGrdXAOdvAf1Xc08AxZICdQ C484tEW0OEXvdZwnOdhEWsa+9eAUfEXqf2ffldUlHDJisZfPdLvd9x/IT5O6bDRQSvEU U6mdHWqFzS3QHEU8os2pFZFbHiAElmPOPR76qj/0EBPAnChtpVH8HsJmU3TtO1HVKT4I Bijw== X-Forwarded-Encrypted: i=1; AJvYcCW6ZOmV9yKWEw1fByLv4q7U97XDY5weueY//yfbaVdYyGRwEK7biq5JZwGgnYjDyR8zMcs0DL2TgQ==@kvack.org X-Gm-Message-State: AOJu0Ywne3D5xLZQdyroSz8GVXh2QZOlSjwyJTp+JpMr5K5++sjTBZjW 6kz7PmLb8agzhaMksgrCqBjDQo7FOPXKlO7eH+2xZjxVeJwNxy98LHlU5qmAHUKHGENjzaDwrdw TwA67agwRqzb7YM4Au+FvYMQDsyb18O8= X-Google-Smtp-Source: AGHT+IHmtyWEtUHfsKHq9g99tzdBj9RE/tE8KQz7cGobSq9bRFg4XWFxuuR2spfaHirGoTu/774OipIK2eJEqFPls4g= X-Received: by 2002:a05:6512:118e:b0:536:a4d8:916d with SMTP id 2adb3069b0e04-5389fc4d0d6mr1144642e87.34.1727422112023; Fri, 27 Sep 2024 00:28:32 -0700 (PDT) MIME-Version: 1.0 References: <20240925032256.1782-1-fangzheng.zhang@unisoc.com> In-Reply-To: From: zhang fangzheng Date: Fri, 27 Sep 2024 15:28:20 +0800 Message-ID: Subject: Re: [PATCH 0/2] Introduce panic function when slub leaks To: Vlastimil Babka Cc: Hyeonggon Yoo <42.hyeyoo@gmail.com>, Fangzheng Zhang , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Roman Gushchin , Greg KH , linux-mm@kvack.org, linux-kernel@vger.kernel.org, tkjos@google.com, Yuming Han Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Queue-Id: 2758440007 X-Rspamd-Server: rspam01 X-Stat-Signature: aaey3wfkt1gz7fxidkqei1ytpu4z68wj X-HE-Tag: 1727422113-538587 X-HE-Meta: U2FsdGVkX1+uYv08dfuFkC4BByTDjq8lUWlqbuv9R5qWxmPUDp4l0O8KDXUBCKEmy91vxFRdC8pjveThQkSZ/UD2eleMrdV4LB8vLK66swz7PNvBaAdUtURrIhygCdM38clYKBieHHHLGWEUiyCeBlfYqaoT+QeXsZm0aAVmm1/Y3qJH7q/ORvM0Hkx55Ly0OMBKsfacQqQ4d3QG+bYMCniCxw0q5pNcS885ElEJpkHVYRFOkT3wpQZkHg24R6VpCESGV3Y8NErby26U+TFukE/TSPFV+/5zU6Yf3mJGA18H1F87M7L+1VXiUmIgJjJ6VhwN+Tta0kxI6CIdSxV6IiPvr5Nw5JNcCKPzAePmY/GEQsDyDrrPv8Kc3mR8SjOeY0uGDswY9HuM/5/xk1veL9o8jKNlYcQaOCQxAs3II8eqkM6oX/6F5YxCxbm/EtrerKWonCYZaaAPRxih5AeM70s7HaT6GHDQR26oF63awNetqUGKCJIV9nzKRO86C7B1qYhjOqUSjEIm+1cRQGkYDxcrQ2pn7qx9479Z+7Yv/pU1bHki06YVzoe/xSl/zmRQvgRwzVLrsxMcUUTieW4/8XsBnFBEjOUwQ1JAYgF2lgvr4dG02XP4KLsGMkyUUXvvIF9GbtcU6rZ4p7GP9WTIb7f2fQGtshn2XWnZevetQn1JLjcPwmhKxMhqeBvv/XthwiBvvAl+MnmGU+kfImDtAZFo2B6zEGTDZGRmEED7pHdjLY46ABuXz/wHAJ6MYkb0gMsINY/YgSmMFdXXRx01lSxUVmJ7yRSgO/LvbWSHPuv3iNNiVNQ6K8b9N+ZQArGylUWtaVGiY1k6zH155OaLm2hG/PLjMMfaHgVz8Q0f17WvozCz9wjM+emKKrMbol0+Ld3Gi5FvkrDQDq0gh2vAjUVEeb93/2Q+CsYIeQQr8OlqpzYJC9Grv8OAlVJBI/vJF3/eT/ZU73BUVlOrs57 hg5TWQTO pI1m8PMTPobXmP7jX7lSco4BvAifnCbHtr+33lU5bjk+dtEWPJ7DNAwqrj8i1k4EAN1H1lzpVl0KmAn3ENFRio1NwTnW7pGuAT3AVAIl5p+poGmc0Dl9KZFGkvwHVMG+5i+PhKqMQtvD+BYl4oS/F5BayZmfLc/xtvus+GmtBbtV+20WBAVLMF+g8zjSU8e9y2+EVtar5M4eeO9+k/8lEa7T/mWLHTY0Mw14n1U75Li8D3JpmlJLksOQkuMuxIMu1FFiuHfbuEIgNL6nKz9aQo3DXJhPYava0nZVN7HyRGQkloBKK+ECgndU4GY/NJ5ZnUZNejryhQKwOu8k5Y3dHSzBA0FUDQyXzyHba0Ur36OoLmIz7UudCJlzUayCmJs3PK5ib9CNk+u3yjXYRkOVknx7WR3Wj+BNEmG/JAhyH/BKCgAtjbhccGFT7YOyhFJzjVXrCoqfhAmicRoFHLC7GTtlkhAemTMgaS/6ooRCOiC3SYrA= 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 Thu, Sep 26, 2024 at 8:30=E2=80=AFPM Vlastimil Babka wr= ote: > > On 9/25/24 15:18, Hyeonggon Yoo wrote: > > On Wed, Sep 25, 2024 at 12:23=E2=80=AFPM Fangzheng Zhang > > wrote: > >> > >> Hi all, > > > > Hi Fangzheng, > > > >> A method to detect slub leaks by monitoring its usage in real time > >> on the page allocation path of the slub. When the slub occupancy > >> exceeds the user-set value, it is considered that the slub is leaking > >> at this time > > > > I'm not sure why this should be a kernel feature. Why not write a user > > script that parses > > MemTotal: and Slab: part of /proc/meminfo file and generates a log > > entry or an alarm? > > Yes very much agreed. It seems rather arbitrary. Why slab, why not any ot= her > kernel-specific counter in /proc/meminfo? Why include NR_SLAB_RECLAIMABLE= _B > when that's used by caches with shrinkers? Ok, this is because the current consideration is to specifically track the memory usage of the slab module. In the stability test, ie, monkey test, the anr or reboot problem occurs, there is a high probability that the slab occupancy is high when it comes to memory analysis. In addition to directly monitoring leaks in the allocation path, it is also convenient to record the allocation stack information when an exception occurs. > A userspace solution should be straightforward and universal - easily > configurable for different scenarios. > > >> and a panic operation will be triggered immediately. > > > > I don't think it would be a good idea to panic unnecessarily. > > IMO it is not proper to panic when the kernel can still run. > > Yes these days it's practically impossible to add a BUG_ON() for more > serious conditions than this. > > Please don't post new versions addressing specific implementation details > until this fundamental issue is addressed. > > Thanks, > Vlastimil > > > Any thoughts? > > > > Thanks, > > Hyeonggon >