On 31.08.22 21:01, Kent Overstreet wrote: > On Wed, Aug 31, 2022 at 12:47:32PM +0200, Michal Hocko wrote: >> On Wed 31-08-22 11:19:48, Mel Gorman wrote: >>> Whatever asking for an explanation as to why equivalent functionality >>> cannot not be created from ftrace/kprobe/eBPF/whatever is reasonable. >> >> Fully agreed and this is especially true for a change this size >> 77 files changed, 3406 insertions(+), 703 deletions(-) > > In the case of memory allocation accounting, you flat cannot do this with ftrace > - you could maybe do a janky version that isn't fully accurate, much slower, > more complicated for the developer to understand and debug and more complicated > for the end user. > > But please, I invite anyone who's actually been doing this with ftrace to > demonstrate otherwise. > > Ftrace just isn't the right tool for the job here - we're talking about adding > per callsite accounting to some of the fastest fast paths in the kernel. > > And the size of the changes for memory allocation accounting are much more > reasonable: > 33 files changed, 623 insertions(+), 99 deletions(-) > > The code tagging library should exist anyways, it's been open coded half a dozen > times in the kernel already. Hi Kent, independent of the other discussions, if it's open coded already, does it make sense to factor that already-open-coded part out independently of the remainder of the full series here? [I didn't immediately spot if this series also attempts already to replace that open-coded part] -- Thanks, David / dhildenb
