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 7EF61C4332F for ; Wed, 2 Mar 2022 17:28:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 18A328D0002; Wed, 2 Mar 2022 12:28:09 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 139408D0001; Wed, 2 Mar 2022 12:28:09 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0282C8D0002; Wed, 2 Mar 2022 12:28:08 -0500 (EST) 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 E92898D0001 for ; Wed, 2 Mar 2022 12:28:08 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay13.hostedemail.com (Postfix) with ESMTP id B9AFE6208F for ; Wed, 2 Mar 2022 17:28:08 +0000 (UTC) X-FDA: 79200129456.14.AE748E3 Received: from mail-yw1-f181.google.com (mail-yw1-f181.google.com [209.85.128.181]) by imf23.hostedemail.com (Postfix) with ESMTP id 444AE140012 for ; Wed, 2 Mar 2022 17:28:08 +0000 (UTC) Received: by mail-yw1-f181.google.com with SMTP id 00721157ae682-2d07ae0b1c4so26046497b3.11 for ; Wed, 02 Mar 2022 09:28:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Uuao6LtPoxz+SwUeDa6xzf7SfiyP8QP18hPPHG47BUc=; b=q3XRXLhSkdzfXMPqmPGrtL5qKLDaaanmRsuY1OlB+gywhyfQ3P0k2Ty/lLBIx9hngr bIE3qAL4ikUxI5IPrvBeSteXA23/TUiOhOXlNzpa2gQtUgeyGl8Sv+On2Q2+b/ioPLVK y6mGgX6AYdM5qc4LpFsHD+JseMxCAPR3H5Cc4VnjOZ7eV1ADHbYrVBbr9AL8ZR5ElxMn onL1EgPo/RmTTVYw9otAeEqlQaXOudGa8wKxOcCtR9oLm0BoPskgY4WBR6I9166lo/cT W+PbTD8Xdk6xgUjKZon509MUJZNIphLafkMUrZ8a/ku3GC4bjTQpoQ7Ua0dreHWIDPif i76A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Uuao6LtPoxz+SwUeDa6xzf7SfiyP8QP18hPPHG47BUc=; b=t/7EkyxgF279hwk+tYAn6Dx7h6tP5+MMo3KZOjCGy5PhA1mKukrM9lKA3KFcfMyeY4 aq9wXzVY6JsNcr/RYFWP0s/jI8Sk/sj+VVlLpUwerpACJGX/8OQ3y4QaQQn6NDaY7Ytt Fir1bTFbaZUMVRgwJeCf9opMYfHTacC1/gX+URy+KmtRCSVe+w+U04LSOrTdzFmGRzxk laFtuP88jsqLWIsWruhmjdc6Wo+018C9DItaymTbZ2moLGrLLHuUG3rxm5FZzoUwq9m2 K6km/DDVQxxNPGhLN1rnjaJddTy52omwNEF92hzpdOtHBEgT2hghmmaczwv4kka+4py2 Ly1Q== X-Gm-Message-State: AOAM5313dKVDr6eyOExxEUPjo2RD9Cxb9CIEKJ2JQn5ocU7tAs6fWL90 AZC5dcR95+TijMSEiXozF2mpud/hdZPhb7dTGqnikw== X-Google-Smtp-Source: ABdhPJwm2ZWFQ7qE2nk58NylCSEqbiMe0zCq2KvKucwX8DnqEWD9OpvdoQUD/JGXnJ1oLd0rtBKUTnEU1/3Qg3jDPlI= X-Received: by 2002:a81:49d0:0:b0:2db:dc6d:445d with SMTP id w199-20020a8149d0000000b002dbdc6d445dmr9596217ywa.512.1646242087255; Wed, 02 Mar 2022 09:28:07 -0800 (PST) MIME-Version: 1.0 References: <20220225180318.20594-1-vbabka@suse.cz> <024aacf5-ac49-7d04-7293-1e1451ff9029@suse.cz> In-Reply-To: From: Marco Elver Date: Wed, 2 Mar 2022 18:27:30 +0100 Message-ID: Subject: Re: [PATCH 0/5] SLUB debugfs improvements based on stackdepot To: Hyeonggon Yoo <42.hyeyoo@gmail.com> Cc: Mike Rapoport , Vlastimil Babka , David Rientjes , Christoph Lameter , Joonsoo Kim , Pekka Enberg , Roman Gushchin , Andrew Morton , linux-mm@kvack.org, patches@lists.linux.dev, linux-kernel@vger.kernel.org, Oliver Glitta , Faiyaz Mohammed , Jonathan Corbet , Randy Dunlap , Karolina Drobnik Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 444AE140012 X-Stat-Signature: c6ponapotud7dc8zxycmyfydyj3j7wh7 X-Rspam-User: Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=q3XRXLhS; spf=pass (imf23.hostedemail.com: domain of elver@google.com designates 209.85.128.181 as permitted sender) smtp.mailfrom=elver@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Server: rspam07 X-HE-Tag: 1646242088-500537 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, 2 Mar 2022 at 18:02, Hyeonggon Yoo <42.hyeyoo@gmail.com> wrote: [...] > So IMO we have two solutions. > > First solution is only allowing early init and avoiding late init. > (setting a global variable that is visible to stack depot would do this) > > And second solution is to make caller allocate and manage its own hash > table. All of this complexity is because we're trying to make stack_table > global. I think this would be a mistake, because then we have to continuously audit all users of stackdepot and make sure that allocation stack traces don't end up in duplicate hash tables. It's global for a reason. > First solution looks ok if we have few users of stack depot. > But I think we should use second approach if stack depot is growing > more and more callers? The problem here really is just that initialization of stackdepot and slabs can have a cyclic dependency with the changes you're making. I very much doubt there'll be other cases (beyond the allocator itself used by stackdepot) which can introduce such a cyclic dependency. The easiest way to break the cyclic dependency is to initialize stackdepot earlier, assuming it can be determined it is required (in this case it can because the command line is parsed before slab creation). The suggestion with the stack_depot_needed_early variable (like Mike's suggested code) would solve all that. I don't understand the concern about multiple contexts. The problem is just about a cyclic dependency during early init, and I doubt we'll have more of that. Thanks, -- Marco