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 11C4CC7EE21 for ; Thu, 4 May 2023 14:31:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1CFB16B0075; Thu, 4 May 2023 10:31:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 15A6A6B0078; Thu, 4 May 2023 10:31:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 021956B007B; Thu, 4 May 2023 10:31:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from mail-yb1-f181.google.com (mail-yb1-f181.google.com [209.85.219.181]) by kanga.kvack.org (Postfix) with ESMTP id CDC656B0075 for ; Thu, 4 May 2023 10:31:17 -0400 (EDT) Received: by mail-yb1-f181.google.com with SMTP id 3f1490d57ef6-b8f34bca001so784095276.3 for ; Thu, 04 May 2023 07:31:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1683210677; x=1685802677; 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=JS6msPuToyJynO3sTVIKpHDiqUqJNNgVeQDo4ExI+FY=; b=B5odhRz5pl82Qodj9r2guUYfauBi1/TsFjLxRQqEz3zjcJjd//DMmZjNJKPPi7+nQ5 xuKBZ6j/WQW0W3dcKfsj589Fsc+uJ6BYPO2OLNobtTmF3hvusxOFblAjFzy4VuEOrD27 shVv5j4flGfZP5ZKf0oD9z3I5mcfEgazfAAXF3El44hYhX1ZRJaYFp+RYh8KC456HFZc kSCAd/ObzJ2UJVsrp6Z49s4y6jg7flU32RKu03oDmXNXsZW8yRicseUXEdJ33k/uoDns 3t9BrSAOH3jBGP78RFzGvpDDNA510GhlcIeVQC/3SRIP7nZ/gPC/uJcOwTrT82pyTD6i AF6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683210677; x=1685802677; 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=JS6msPuToyJynO3sTVIKpHDiqUqJNNgVeQDo4ExI+FY=; b=QuXI774Rmg+Eai7B1wZ35xvt36vt2lrB8+cjUbFbDUTpLPHHXL3ATsUQobM0WHhozT geOYKa/+o+lD/HJ8xhURfa1rKeDMg5HRLpQGwGANnAAf5Du+0uDYRUPKQqooUBSQVSZX gLf8f7ai8jh4oGfuFnkIorgSe/4RD0QKhGrVfbG9hrAdGTgg/ORKRDERLj6KsYJKzm7d mTYWmVKu0w9DCciQdeS/X+lZS6/PnntSqWrz9ZXB29PC+/4d/btbYWoHuDPUDRQSfUIK kSwZtXg6snAFpPqEUT556XhHiMcHpLOpUOFKjg+X5h1w7E96Ie0BY96ah1VIpts0I8Ue tfeA== X-Gm-Message-State: AC+VfDxZ7qAkNI3m/r15pQpug5DJRw3kIU+pJfYygUCOWv1Z8hD2uOJf aBRKDoWB9Z0xgCvtMeJFUhkwrl0AuUVv5WtW5nxZqA== X-Google-Smtp-Source: ACHHUZ5E9WXnTl16LxgdrH+7bPTNFRvDYVSM0w82lR/qVCCtHXAzvUBD8IG8coi/bDLOeNuU/XqnEJgf+6xYt7++7Tk= X-Received: by 2002:a25:cec1:0:b0:b99:4ac6:3c75 with SMTP id x184-20020a25cec1000000b00b994ac63c75mr122983ybe.10.1683210677091; Thu, 04 May 2023 07:31:17 -0700 (PDT) MIME-Version: 1.0 References: <20230501165450.15352-1-surenb@google.com> <20230501165450.15352-35-surenb@google.com> In-Reply-To: From: Suren Baghdasaryan Date: Thu, 4 May 2023 07:31:05 -0700 Message-ID: Subject: Re: [PATCH 34/40] lib: code tagging context capture support To: Michal Hocko Cc: akpm@linux-foundation.org, kent.overstreet@linux.dev, vbabka@suse.cz, hannes@cmpxchg.org, roman.gushchin@linux.dev, mgorman@suse.de, dave@stgolabs.net, willy@infradead.org, liam.howlett@oracle.com, corbet@lwn.net, void@manifault.com, peterz@infradead.org, juri.lelli@redhat.com, ldufour@linux.ibm.com, catalin.marinas@arm.com, will@kernel.org, arnd@arndb.de, tglx@linutronix.de, mingo@redhat.com, dave.hansen@linux.intel.com, x86@kernel.org, peterx@redhat.com, david@redhat.com, axboe@kernel.dk, mcgrof@kernel.org, masahiroy@kernel.org, nathan@kernel.org, dennis@kernel.org, tj@kernel.org, muchun.song@linux.dev, rppt@kernel.org, paulmck@kernel.org, pasha.tatashin@soleen.com, yosryahmed@google.com, yuzhao@google.com, dhowells@redhat.com, hughd@google.com, andreyknvl@gmail.com, keescook@chromium.org, ndesaulniers@google.com, gregkh@linuxfoundation.org, ebiggers@google.com, ytcoode@gmail.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, bristot@redhat.com, vschneid@redhat.com, cl@linux.com, penberg@kernel.org, iamjoonsoo.kim@lge.com, 42.hyeyoo@gmail.com, glider@google.com, elver@google.com, dvyukov@google.com, shakeelb@google.com, songmuchun@bytedance.com, jbaron@akamai.com, rientjes@google.com, minchan@google.com, kaleshsingh@google.com, kernel-team@android.com, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, iommu@lists.linux.dev, linux-arch@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-modules@vger.kernel.org, kasan-dev@googlegroups.com, cgroups@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 Thu, May 4, 2023 at 1:04=E2=80=AFAM Michal Hocko wrote= : > > On Wed 03-05-23 08:18:39, Suren Baghdasaryan wrote: > > On Wed, May 3, 2023 at 12:36=E2=80=AFAM Michal Hocko = wrote: > > > > > > On Mon 01-05-23 09:54:44, Suren Baghdasaryan wrote: > > > [...] > > > > +static inline void add_ctx(struct codetag_ctx *ctx, > > > > + struct codetag_with_ctx *ctc) > > > > +{ > > > > + kref_init(&ctx->refcount); > > > > + spin_lock(&ctc->ctx_lock); > > > > + ctx->flags =3D CTC_FLAG_CTX_PTR; > > > > + ctx->ctc =3D ctc; > > > > + list_add_tail(&ctx->node, &ctc->ctx_head); > > > > + spin_unlock(&ctc->ctx_lock); > > > > > > AFAIU every single tracked allocation will get its own codetag_ctx. > > > There is no aggregation per allocation site or anything else. This lo= oks > > > like a scalability and a memory overhead red flag to me. > > > > True. The allocations here would not be limited. We could introduce a > > global limit to the amount of memory that we can use to store contexts > > and maybe reuse the oldest entry (in LRU fashion) when we hit that > > limit? > > Wouldn't it make more sense to aggregate same allocations? Sure pids > get recycled but quite honestly I am not sure that information is all > that interesting. Precisely because of the recycle and short lived > processes reasons. I think there is quite a lot to think about the > detailed context tracking. That would be a nice optimization. I'll need to look into the implementation details. Thanks for the idea. > > > > > > > > +} > > > > + > > > > +static inline void rem_ctx(struct codetag_ctx *ctx, > > > > + void (*free_ctx)(struct kref *refcount)) > > > > +{ > > > > + struct codetag_with_ctx *ctc =3D ctx->ctc; > > > > + > > > > + spin_lock(&ctc->ctx_lock); > > > > > > This could deadlock when allocator is called from the IRQ context. > > > > I see. spin_lock_irqsave() then? > > yes. I have checked that the lock is not held over the all list > traversal which is good but the changelog could be more explicit about > the iterators and lock hold times implications. Ack. Will add more information. > > -- > Michal Hocko > SUSE Labs