From: Arnd Bergmann <[email protected]>
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 <[email protected]>
[ Viresh: Update the name in #endif part ]
Signed-off-by: Viresh Kumar <[email protected]>
---
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
Looks good:
Reviewed-by: Christoph Hellwig <[email protected]>
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 <[email protected]>
>
> 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 <[email protected]>
> [ Viresh: Update the name in #endif part ]
> Signed-off-by: Viresh Kumar <[email protected]>
> ---
> 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 <[email protected]> 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 Wed, Oct 28, 2020 at 5:34 PM William Cohen <[email protected]> wrote:
>
> On 10/27/20 12:54 PM, Linus Torvalds wrote:
> > On Tue, Oct 27, 2020 at 1:52 AM Christoph Hellwig <[email protected]> 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 10/27/20 12:54 PM, Linus Torvalds wrote:
> On Tue, Oct 27, 2020 at 1:52 AM Christoph Hellwig <[email protected]> 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 20-10-20, 16:31, Viresh Kumar wrote:
> From: Arnd Bergmann <[email protected]>
>
> 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 <[email protected]>
> [ Viresh: Update the name in #endif part ]
> Signed-off-by: Viresh Kumar <[email protected]>
> ---
> 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.
--
viresh
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 <[email protected]> wrote:
>
> On Wed, Oct 28, 2020 at 5:34 PM William Cohen <[email protected]> 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