[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230503092128.1a120845@gandalf.local.home>
Date: Wed, 3 May 2023 09:21:28 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Kent Overstreet <kent.overstreet@...ux.dev>
Cc: Michal Hocko <mhocko@...e.com>,
Suren Baghdasaryan <surenb@...gle.com>,
akpm@...ux-foundation.org, vbabka@...e.cz, hannes@...xchg.org,
roman.gushchin@...ux.dev, mgorman@...e.de, dave@...olabs.net,
willy@...radead.org, liam.howlett@...cle.com, corbet@....net,
void@...ifault.com, peterz@...radead.org, juri.lelli@...hat.com,
ldufour@...ux.ibm.com, catalin.marinas@....com, will@...nel.org,
arnd@...db.de, tglx@...utronix.de, mingo@...hat.com,
dave.hansen@...ux.intel.com, x86@...nel.org, peterx@...hat.com,
david@...hat.com, axboe@...nel.dk, mcgrof@...nel.org,
masahiroy@...nel.org, nathan@...nel.org, dennis@...nel.org,
tj@...nel.org, muchun.song@...ux.dev, rppt@...nel.org,
paulmck@...nel.org, pasha.tatashin@...een.com,
yosryahmed@...gle.com, yuzhao@...gle.com, dhowells@...hat.com,
hughd@...gle.com, andreyknvl@...il.com, keescook@...omium.org,
ndesaulniers@...gle.com, gregkh@...uxfoundation.org,
ebiggers@...gle.com, ytcoode@...il.com, vincent.guittot@...aro.org,
dietmar.eggemann@....com, bsegall@...gle.com, bristot@...hat.com,
vschneid@...hat.com, cl@...ux.com, penberg@...nel.org,
iamjoonsoo.kim@....com, 42.hyeyoo@...il.com, glider@...gle.com,
elver@...gle.com, dvyukov@...gle.com, shakeelb@...gle.com,
songmuchun@...edance.com, jbaron@...mai.com, rientjes@...gle.com,
minchan@...gle.com, kaleshsingh@...gle.com,
kernel-team@...roid.com, linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org, iommu@...ts.linux.dev,
linux-arch@...r.kernel.org, linux-fsdevel@...r.kernel.org,
linux-mm@...ck.org, linux-modules@...r.kernel.org,
kasan-dev@...glegroups.com, cgroups@...r.kernel.org
Subject: Re: [PATCH 00/40] Memory allocation profiling
On Wed, 3 May 2023 04:05:08 -0400
Kent Overstreet <kent.overstreet@...ux.dev> wrote:
> > The burden is on you and Suren. You are proposing the implement an
> > alternative tracing infrastructure.
>
> No, we're still waiting on the tracing people to _demonstrate_, not
> claim, that this is at all possible in a comparable way with tracing.
It's not my job to do your work for you!
I gave you hints on how you can do this with attaching to existing trace
events and your response was "If you don't think it's hard, go ahead and
show us." No! I'm too busy with my own work to do free work for you!
https://lore.kernel.org/all/20220905235007.sc4uk6illlog62fl@kmo-framework/
I know it's easier to create something from scratch that you fully know,
than to work with an existing infrastructure that you need to spend effort
and learn to make it do what you want. But by recreating the work, you now
pass the burden onto everyone else that needs to learn what you did. Not to
mention, we would likely have multiple ways to do the same thing.
Sorry, but that's not how an open source community is suppose to work.
-- Steve
Powered by blists - more mailing lists