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 70341C3DA4A for ; Sun, 11 Aug 2024 20:21:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F0B1D6B008A; Sun, 11 Aug 2024 16:21:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E93F56B0092; Sun, 11 Aug 2024 16:21:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D0D696B0095; Sun, 11 Aug 2024 16:21:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 80F4D6B008A for ; Sun, 11 Aug 2024 16:21:58 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id DCA8AA87E2 for ; Sun, 11 Aug 2024 20:21:57 +0000 (UTC) X-FDA: 82441085874.05.428CD64 Received: from mail-pl1-f180.google.com (mail-pl1-f180.google.com [209.85.214.180]) by imf25.hostedemail.com (Postfix) with ESMTP id 17B16A0014 for ; Sun, 11 Aug 2024 20:21:55 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=lD3bB8Gh; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf25.hostedemail.com: domain of rientjes@google.com designates 209.85.214.180 as permitted sender) smtp.mailfrom=rientjes@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1723407705; a=rsa-sha256; cv=none; b=JEf3UUAm5Ocdn7ogltmfFh9P624ufYyxn3ZmgezPZ+Op5vddmmYDyjlV0un3rjDJICQwOU uHiw+9Qg6sbmQNpLMxR7u4OamW2aYdLoH5/LJDeIPX3XeZeprJBqWdzNj1QSGvJiHAnMMf yZvs/TowoYgpDV8J+Uf9euFNceutmgc= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=lD3bB8Gh; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf25.hostedemail.com: domain of rientjes@google.com designates 209.85.214.180 as permitted sender) smtp.mailfrom=rientjes@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1723407705; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=5Y39ocZR3ybGuuhWSwlGuXQ5fKfzXZURWW4sanMk1Rs=; b=af19L9mKcCDer7zKITiTPHFbqEWEcOqPJM6VoYx30sEUsBIfS8kOSYKVEUfaHEuObB9fPB mcfEd9xCtxXesYrzDo8pe6YyFNFOW5Ko2KSfltBmIWr6n9QLn4EuvUGFfZ9PmpjVUsTHnK 8upuekaEwEbrBgOuSwOcmmek8YzRJXs= Received: by mail-pl1-f180.google.com with SMTP id d9443c01a7336-1fd657c9199so163045ad.1 for ; Sun, 11 Aug 2024 13:21:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1723407715; x=1724012515; darn=kvack.org; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to; bh=5Y39ocZR3ybGuuhWSwlGuXQ5fKfzXZURWW4sanMk1Rs=; b=lD3bB8GhJzVW1bVY7SGn6KmHAHu1Wl1VZO3VqZ+A6AlvqOAPvzS6USvMHHiXvKCOW0 HkkFHzcg3cQosqNHXwWBmLRzwuaBFhRPNLn+gWdd5Ed7cKPYMiVTa6tKkeRRSr4y7dm3 8WJdPn8qaDArN7NDnFP3CjopVUYW6BjfXDHBMM9SH8lo+POeVjaZ32y4fePgqCmQXFay SdIOx5W0GQE87XlUS36n95X4Hw1vEaRE0OYSQqQnPqVHnGfZFoXmmjCWHsiQ8i0R6Qkp LeQW6cO3VHBWv0p1Mly8neHp/g/IXBjvdKKkOMMRiFOTD0rfQy7HJjWY7PcdlwNjR+zP L7Lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723407715; x=1724012515; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=5Y39ocZR3ybGuuhWSwlGuXQ5fKfzXZURWW4sanMk1Rs=; b=ukb3Ok2iAeBHEqyhQeM2sMe/szPQ0slJoMLkoz2CKPbmyeXGrfR+zZhbAqNOxg36L5 1Ybobqni8VT7jWYspeasq/PLPmxBgSoMoxgUfXZRL4tm/ejw3LhSEIPHjwjKCtq6TYWK jSCcHYMyTBXDateRhj84zTI3sgeZUADCKF54H3mP1D60qxocG7LgLAULWTiCn6xuFkku NmCnVTaOXDcHkxNUL9mQC1R1My0gXQv8lTw53YGiW0MTQ5Lao4aPltwdd03+2Vm2Ib1P vni1/iO49ndJQxW2OnqjiBLQ4mUUP05TgBMYgP/hxOPNVzlO3oQmUwwTOTT0StAhKRFc A9zQ== X-Forwarded-Encrypted: i=1; AJvYcCWZv8yhQue2RE/TZ8vsS9zMRt7e++tUey/KPOx0HPSztuUqQaywwXChRifr7tDE/CFXg1CWP6vrOAwHfJod04ftcSQ= X-Gm-Message-State: AOJu0YycbLx+oZ883/JK4qAybYs/D/lSonCi/KSjy/2Y6PM6N2ljZZXs rWwBgjvjBvJdwOX/3h1bTerazRitFl3D4yH2eTZb8Gv4zd/e6QO9tKgecSG1YA== X-Google-Smtp-Source: AGHT+IEKhuskO4u6WdIOWmXXHKq52K3lHUQHBEitTHtSryDG+qLr7BByebpaZ02yRHU/2ntsB/h0wg== X-Received: by 2002:a17:902:ecc3:b0:1fd:d807:b29d with SMTP id d9443c01a7336-200bbe22dcfmr3255445ad.28.1723407714169; Sun, 11 Aug 2024 13:21:54 -0700 (PDT) Received: from [2620:0:1008:15:49ba:9fa:21c6:8a73] ([2620:0:1008:15:49ba:9fa:21c6:8a73]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-200bb903b09sm25705365ad.95.2024.08.11.13.21.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 11 Aug 2024 13:21:53 -0700 (PDT) Date: Sun, 11 Aug 2024 13:21:52 -0700 (PDT) From: David Rientjes To: Vlastimil Babka cc: Axel Rasmussen , Andrew Morton , Christoph Lameter , Hyeonggon Yoo <42.hyeyoo@gmail.com>, Joonsoo Kim , Pekka Enberg , Roman Gushchin , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH] mm, slub: print CPU id on slab OOM In-Reply-To: Message-ID: <6951700d-b6c0-b9b7-6587-1823a9d8c63d@google.com> References: <20240806232649.3258741-1-axelrasmussen@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Rspam-User: X-Rspamd-Queue-Id: 17B16A0014 X-Rspamd-Server: rspam01 X-Stat-Signature: k5nk916p7yep46ioza3jrc85hdtkyhnp X-HE-Tag: 1723407715-378378 X-HE-Meta: U2FsdGVkX1/n2pekxIcQKJ2XzHY3hQz+vG2GOPzebr9f5eIwvrOJPcifuFwNz90QqyRjTDFVz0fYN19elYMvL8dFZv5MKdVtQJ5PBKI/8LJQU5KXDxW/8wobXCWkcqOpa9t38QmxuAZ8ylHHI1CuiCrbhE23W6Yv+SL6rXLkakGAE4m+xpxNAPLOpBFtg5fuz/kVsc+BsuTvlMYgOKtBOAixKlUNrTy1p1H8gTX/6t459JVsgY9fgmlRVUKFGrPk1z/3zIkL5CDUzCtBQ5EF2g5oAK69XODCPT62rDZs4yrF//Dx6p4rt5lTOuy7/RUjrg6Khw/T09HzLveX83sCkpZFUOZPGPJZB4H1rilYBWuxAMk1+gqstA49oCRzkpzp3/v/96tXBEgjcx1KoOjhmdGTvjlqgZsuacdxFI6N3bn1FXK5HQBRFzCglxvxZsE1FIG0qSUFbNjQxmrwczWclh4JloV/5b7AAsDq9YwGcH6PX8BCPjEhKsW1ExcQzyIDobgSpqYczpjHtudVrkI/tYYckIzGRQIga1i1BGmr1GAAr6nWC5UmMYBbPP123dXUVfaqPO+U/RAOEReNR2wSplcJHG510nejKO3tgGmO6DHlI4rq7uwAzXSmFcMLRWy8au30bJLk0VQJqfWe+bBtMj+M31UW4p+CqsI1pvFeGqQJ1Ez9z+t78eZT/RLDTTd62GyHNjM05o1JAK9MvGKbsDQqjM1iOWM9kQGnEFHjy8dPUTE2b6b2UJCTljDuJZBXi7l2p3jZ/F5H5gbiXbiMe4UoTYmJtBjY/GDp5gwCbtV+CZIFSPrNcgB50DVIwJa2x+TdWJE5YQ9Dv2btsq9jyDcWOR54aX1HowAJollPcYe9y+9019ny/Bi8c/KQMUUpr8jnoS7ximkFdzeT7z1CG6Tn75PQlu0dh64AE9zSVlDFsAIcQ5U4niDk3InZTsNDCOy9XCJPx/smpe2ev6Z 962JyfQ7 MKHNhzqp7GNk+4JiPzR9Sg2ZUtXVR0f0WqtZD4L0aju6OExCfb47HpXtocPTl6T06RhJOrPTUoJdN1C2q3AB65LoVlMCdkiCn0255RNwBmuRJ/dQIvJCHPD54ZBJdSBVsU8Mr7pYPLwXgjMGjIeKcuFrMekpJAe3plo/Vf0HHJv6l+Br8QpNrkBlHJ/nYDqSalaiAI1+XBv631V8R/j5IiK55YflddoUsN6kUUM3jDjgWINWGsBGk8MHQ50PL/EMeO8t6tn9dhZ7Cs8BJ6JmIhQkGr7jXNcCCt05sRx58Z/+iVP2J5sYtxqAKpyYICey1zU1p6yEHJxYFydPKReSAYgBgy2prD85LiWgaLCc5B3rR9Oeu/JNTjJEj6BK1XSCZVxZqKY1zm9SM3B7hYjf5npm/eJ/0JL6M2AF0 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 Sun, 11 Aug 2024, Vlastimil Babka wrote: > > diff --git a/mm/slub.c b/mm/slub.c > > index c9d8a2497fd6..7148047998de 100644 > > --- a/mm/slub.c > > +++ b/mm/slub.c > > @@ -3422,7 +3422,8 @@ slab_out_of_memory(struct kmem_cache *s, gfp_t gfpflags, int nid) > > if ((gfpflags & __GFP_NOWARN) || !__ratelimit(&slub_oom_rs)) > > return; > > > > - pr_warn("SLUB: Unable to allocate memory on node %d, gfp=%#x(%pGg)\n", > > + pr_warn("SLUB: Unable to allocate memory for CPU %u on node %d, gfp=%#x(%pGg)\n", > > BTW, wouldn't "on CPU" be more correct, as "for CPU" might be misleading > that we are somehow constrained to that CPU? > Agreed. When I suggested this patch, I was trying to ascertain whether something was really wonky based on some logs that we were seeing. node 0: slabs: 223, objs: 11819, free: 0 node 1: slabs: 951, objs: 50262, free: 218 This is for a NUMA_NO_NODE allocation, so I wanted to know if the cpu was on node 0 or node 1. Even with the patch, that requires knowing the cpu-to-node mapping. If we add the CPU output here, we likely also want to print out cpu_to_node(). > > + preemptible() ? raw_smp_processor_id() : smp_processor_id(), > > Also could we just use raw_smp_processor_id() always here? I don't see > this has any advantage or am I missing something? > This matches my understanding as well.