From: Ingo Molnar <mingo@kernel.org>
To: Borislav Petkov <bp@alien8.de>
Cc: Peter Zijlstra <peterz@infradead.org>,
lkml <linux-kernel@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Arnaldo Carvalho de Melo <acme@infradead.org>,
Jiri Olsa <jolsa@redhat.com>, Namhyung Kim <namhyung@kernel.org>
Subject: Re: Reorganize perf kernel side
Date: Sun, 6 Dec 2015 10:54:06 +0100 [thread overview]
Message-ID: <20151206095406.GB4022@gmail.com> (raw)
In-Reply-To: <20151204211756.GR21177@pd.tnic>
* Borislav Petkov <bp@alien8.de> wrote:
> Hi guys,
>
> so I've had my eyes on this for a long time now and it has managed to
> get on my nerves just enough to do something about it :-)
>
> So how about moving perf stuff to arch/x86/perf/ and get rid of the
> prefixes in the filenames. This also flattens our folder structure which
> is a good thing and which we've been talking about in the past.
>
> In order to diminish churn, I can do the whole thing in 4-5 patches'
> sets, after having run enough *config smoke tests and 0day bot too.
> Anyway, something like that.
>
> perf_event_<vendor>_<type>.c
>
> can then move to arch/x86/perf/<vendor>/type.c
>
> and have much saner structure.
>
> Thoughts?
Yeah, it would be lovely if you could do that - but could we please name it
'events' instead of 'perf', to follow the existing namespace pattern we are using
for the core bits, where we have kernel/events/ for the core bits, not
kernel/perf/?
Also, how about naming the core x86 bits like this:
arch/x86/events/core.c
which would give us a clear path to split-out core functionality eventually, such
as:
arch/x86/events/sched.c
arch/x86/events/constraints.c
...etc...
...
Just like we've already split out functionality from kernel/events/core.c into
kernel/events/ring_buffer.c.
Btw., kernel/sched/ is using a similar approach, there's core.c, and various
split-out sub-modules. We are slowly migrating from the original humunguous
kernel/sched.c to a more finegrained kernel/sched/subsys.c structure.
... and as you suggested, the x86 vendor dependent bits would be in their own, but
easily accessible directory close to the core, as you suggested:
arch/x86/events/intel/
arch/x86/events/amd/
...
as a lot of work is happening in that space, so promoting it up in the namespace
helps.
So, as an example, we'd have renames like this:
arch/x86/kernel/cpu/perf_event_intel_uncore_nhmex.c
=> arch/x86/events/intel/uncore_nhmex.c
which will be 30% easier to type! Once our muscle memory has re-trained that is. ;-)
Thanks,
Ingo
prev parent reply other threads:[~2015-12-06 9:54 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-04 21:17 Reorganize perf kernel side Borislav Petkov
2015-12-04 22:09 ` Peter Zijlstra
2015-12-04 22:40 ` Borislav Petkov
2015-12-06 9:54 ` Ingo Molnar [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151206095406.GB4022@gmail.com \
--to=mingo@kernel.org \
--cc=acme@infradead.org \
--cc=bp@alien8.de \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.