| Message ID | 51a9a594a38ae6e0982e78976cf046fb55b63a8e.1603191669.git.viresh.kumar@linaro.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | dcookies: Make dcookies depend on CONFIG_OPROFILE | expand |
Looks good: Reviewed-by: Christoph Hellwig <hch@lst.de> Is it time to deprecate and eventually remove oprofile while we're at it? On Tue, Oct 20, 2020 at 04:31:27PM +0530, Viresh Kumar wrote: > From: Arnd Bergmann <arnd@arndb.de> > > The dcookies stuff is used only with OPROFILE and there is no need to > build it if CONFIG_OPROFILE isn't enabled. Build it depending on > CONFIG_OPROFILE instead of CONFIG_PROFILING. > > Signed-off-by: Arnd Bergmann <arnd@arndb.de> > [ Viresh: Update the name in #endif part ] > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> > --- > fs/Makefile | 2 +- > include/linux/dcookies.h | 4 ++-- > 2 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/fs/Makefile b/fs/Makefile > index 7bb2a05fda1f..a7b3d9ff8db5 100644 > --- a/fs/Makefile > +++ b/fs/Makefile > @@ -64,7 +64,7 @@ obj-$(CONFIG_SYSFS) += sysfs/ > obj-$(CONFIG_CONFIGFS_FS) += configfs/ > obj-y += devpts/ > > -obj-$(CONFIG_PROFILING) += dcookies.o > +obj-$(CONFIG_OPROFILE) += dcookies.o > obj-$(CONFIG_DLM) += dlm/ > > # Do not add any filesystems before this line > diff --git a/include/linux/dcookies.h b/include/linux/dcookies.h > index ddfdac20cad0..8617c1871398 100644 > --- a/include/linux/dcookies.h > +++ b/include/linux/dcookies.h > @@ -11,7 +11,7 @@ > #define DCOOKIES_H > > > -#ifdef CONFIG_PROFILING > +#ifdef CONFIG_OPROFILE > > #include <linux/dcache.h> > #include <linux/types.h> > @@ -64,6 +64,6 @@ static inline int get_dcookie(const struct path *path, unsigned long *cookie) > return -ENOSYS; > } > > -#endif /* CONFIG_PROFILING */ > +#endif /* CONFIG_OPROFILE */ > > #endif /* DCOOKIES_H */ > -- > 2.25.0.rc1.19.g042ed3e048af > ---end quoted text---
On Tue, Oct 27, 2020 at 1:52 AM Christoph Hellwig <hch@infradead.org> wrote: > > Is it time to deprecate and eventually remove oprofile while we're at > it? I think it's well past time. I think the user-space "oprofile" program doesn't actually use the legacy kernel code any more, and hasn't for a long time. But I might be wrong. Adding William Cohen to the cc, since he seems to still maintain it to make sure it builds etc. Linus
On 10/27/20 12:54 PM, Linus Torvalds wrote: > On Tue, Oct 27, 2020 at 1:52 AM Christoph Hellwig <hch@infradead.org> wrote: >> >> Is it time to deprecate and eventually remove oprofile while we're at >> it? > > I think it's well past time. > > I think the user-space "oprofile" program doesn't actually use the > legacy kernel code any more, and hasn't for a long time. > > But I might be wrong. Adding William Cohen to the cc, since he seems > to still maintain it to make sure it builds etc. > > Linus > Hi, Yes, current OProfile code uses the existing linux perf infrastructure and doesn't use the old oprofile kernel code. I have thought about removing that old oprofile driver code from kernel, but have not submitted patches for it. I would be fine with eliminating that code from the kernel. -Will
On Wed, Oct 28, 2020 at 5:34 PM William Cohen <wcohen@redhat.com> wrote: > > On 10/27/20 12:54 PM, Linus Torvalds wrote: > > On Tue, Oct 27, 2020 at 1:52 AM Christoph Hellwig <hch@infradead.org> wrote: > >> > >> Is it time to deprecate and eventually remove oprofile while we're at > >> it? > > > > I think it's well past time. > > > > I think the user-space "oprofile" program doesn't actually use the > > legacy kernel code any more, and hasn't for a long time. > > > > But I might be wrong. Adding William Cohen to the cc, since he seems > > to still maintain it to make sure it builds etc. > > Yes, current OProfile code uses the existing linux perf infrastructure and > doesn't use the old oprofile kernel code. I have thought about removing > that old oprofile driver code from kernel, but have not submitted patches > for it. I would be fine with eliminating that code from the kernel. I notice that arch/ia64/ supports oprofile but not perf. I suppose this just means that ia64 people no longer care enough about profiling to add perf support, but it wouldn't stop us from dropping it, right? There is also a stub implementation of oprofile for microblaze and no perf code, not sure if it would make any difference for them. Everything else that has oprofile kernel code also supports perf. Arnd
On 20-10-20, 16:31, Viresh Kumar wrote: > From: Arnd Bergmann <arnd@arndb.de> > > The dcookies stuff is used only with OPROFILE and there is no need to > build it if CONFIG_OPROFILE isn't enabled. Build it depending on > CONFIG_OPROFILE instead of CONFIG_PROFILING. > > Signed-off-by: Arnd Bergmann <arnd@arndb.de> > [ Viresh: Update the name in #endif part ] > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> > --- > fs/Makefile | 2 +- > include/linux/dcookies.h | 4 ++-- > 2 files changed, 3 insertions(+), 3 deletions(-) Alexander, Ping for picking up this patch for 5.11. Thanks.
Just reviving this thread to see if we could get rid of the OPROFILE
kernel code this time..
One option is to just start off with adding a
depends on DISABLED
on the OPROFILE config option, and see if anybody even notices.
But honestly, just removing the entirely might be the better thing.
The oprofile config is a bit odd. We have things like
OPROFILE_NMI_TIMER which defaults to on even if OPROFILE isn't even
selected. All the _users_ of that seem to be inside oprofile code, so
it's effectively a no-op without oprofile,
The only reason I noticed was that I looked at the Fedora kernel
config files, and went "uhhuh, Fedora still enables that", and had a
quick worry before I noticed that it's just the Kconfig system being
silly.
Linus
On Wed, Oct 28, 2020 at 11:01 AM Arnd Bergmann <arnd@kernel.org> wrote:
>
> On Wed, Oct 28, 2020 at 5:34 PM William Cohen <wcohen@redhat.com> wrote:
> >
> > On 10/27/20 12:54 PM, Linus Torvalds wrote:
> > >
> > > I think the user-space "oprofile" program doesn't actually use the
> > > legacy kernel code any more, and hasn't for a long time.
> >
> > Yes, current OProfile code uses the existing linux perf infrastructure and
> > doesn't use the old oprofile kernel code. I have thought about removing
> > that old oprofile driver code from kernel, but have not submitted patches
> > for it. I would be fine with eliminating that code from the kernel.
>
> I notice that arch/ia64/ supports oprofile but not perf. I suppose this just
> means that ia64 people no longer care enough about profiling to
> add perf support, but it wouldn't stop us from dropping it, right?
>
> There is also a stub implementation of oprofile for microblaze
> and no perf code, not sure if it would make any difference for them.
>
> Everything else that has oprofile kernel code also supports perf.
>
> Arnd
diff --git a/fs/Makefile b/fs/Makefile index 7bb2a05fda1f..a7b3d9ff8db5 100644 --- a/fs/Makefile +++ b/fs/Makefile @@ -64,7 +64,7 @@ obj-$(CONFIG_SYSFS) += sysfs/ obj-$(CONFIG_CONFIGFS_FS) += configfs/ obj-y += devpts/ -obj-$(CONFIG_PROFILING) += dcookies.o +obj-$(CONFIG_OPROFILE) += dcookies.o obj-$(CONFIG_DLM) += dlm/ # Do not add any filesystems before this line diff --git a/include/linux/dcookies.h b/include/linux/dcookies.h index ddfdac20cad0..8617c1871398 100644 --- a/include/linux/dcookies.h +++ b/include/linux/dcookies.h @@ -11,7 +11,7 @@ #define DCOOKIES_H -#ifdef CONFIG_PROFILING +#ifdef CONFIG_OPROFILE #include <linux/dcache.h> #include <linux/types.h> @@ -64,6 +64,6 @@ static inline int get_dcookie(const struct path *path, unsigned long *cookie) return -ENOSYS; } -#endif /* CONFIG_PROFILING */ +#endif /* CONFIG_OPROFILE */ #endif /* DCOOKIES_H */