Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1421044 > unrolled thread

Re: [PATCH] s390/oprofile: Remove deprecated create_workqueue

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] s390/oprofile: Remove deprecated create_workqueue Robert Richter <rric@kernel.org> - 2016-06-13 18:30 +0200
    Re: [PATCH] s390/oprofile: Remove deprecated create_workqueue William Cohen <wcohen@redhat.com> - 2016-06-13 22:50 +0200
    Re: [PATCH] s390/oprofile: Remove deprecated create_workqueue Heiko Carstens <heiko.carstens@de.ibm.com> - 2016-06-14 07:40 +0200
      Re: [PATCH] s390/oprofile: Remove deprecated create_workqueue Robert Richter <rric@kernel.org> - 2016-06-14 15:30 +0200
        Re: [PATCH] s390/oprofile: Remove deprecated create_workqueue Hendrik Brueckner <brueckner@linux.vnet.ibm.com> - 2016-06-17 11:10 +0200

#1421044 — Re: [PATCH] s390/oprofile: Remove deprecated create_workqueue

Heiko,

On 09.06.16 11:00:56, Heiko Carstens wrote:
> However I'm wondering if we shouldn't simply remove at least the s390
> specific hwswampler code from the oprofile module. This would still leave
> the common code timer based sampling mode for oprofile working on s390.
> 
> It looks like the oprofile user space utility nowadays (since 2012) uses
> the kernel perf interface instead of the oprofile interface anyway, if
> present. So the oprofile module itself doesn't seem to have too many users
> left.
> 
> Any opinions?

yes, the kernel driver is not necessary for oprofile userland for a
while now. There is no ongoing development any longer, most patches
are due to changes in the kernel apis.

So if there is code that needs a larger rework due to other kernel
changes and there is no user anymore, I am fine with removing the code
instead of reworking it. I still would just keep existing code as long
as we can keep it unchanged (some like the lightwight of oprofile,
esp. in the embedded space). If there is a user of the code, a
Tested-by would be good for new code changes.

If there are users of the hwswampler, speak up now. Else, let's just
remove it.

-Robert

[toc] | [next] | [standalone]

#1421301

On 06/13/2016 12:29 PM, Robert Richter wrote:
> Heiko,
> 
> On 09.06.16 11:00:56, Heiko Carstens wrote:
>> However I'm wondering if we shouldn't simply remove at least the s390
>> specific hwswampler code from the oprofile module. This would still leave
>> the common code timer based sampling mode for oprofile working on s390.
>>
>> It looks like the oprofile user space utility nowadays (since 2012) uses
>> the kernel perf interface instead of the oprofile interface anyway, if
>> present. So the oprofile module itself doesn't seem to have too many users
>> left.
>>
>> Any opinions?
> 
> yes, the kernel driver is not necessary for oprofile userland for a
> while now. There is no ongoing development any longer, most patches
> are due to changes in the kernel apis.
> 
> So if there is code that needs a larger rework due to other kernel
> changes and there is no user anymore, I am fine with removing the code
> instead of reworking it. I still would just keep existing code as long
> as we can keep it unchanged (some like the lightwight of oprofile,
> esp. in the embedded space). If there is a user of the code, a
> Tested-by would be good for new code changes.
> 
> If there are users of the hwswampler, speak up now. Else, let's just
> remove it.
> 
> -Robert
> 

Hi,

As Robert mentioned the user-space oprofile code that would have used the oprofile device driver was removed around August 2014 in preparation for oprofile-1.0. The operf command which uses the kernel perf infrastructure and does not need for the oprofile kernel driver has been in oprofile since August of 2012.  For some architectures it would make sense to simplify things by eliminate the oprofile kernel driver.

-Will Cohen

[toc] | [prev] | [next] | [standalone]

#1421584

On Mon, Jun 13, 2016 at 06:29:14PM +0200, Robert Richter wrote:
> Heiko,
> 
> On 09.06.16 11:00:56, Heiko Carstens wrote:
> > However I'm wondering if we shouldn't simply remove at least the s390
> > specific hwswampler code from the oprofile module. This would still leave
> > the common code timer based sampling mode for oprofile working on s390.
> > 
> > It looks like the oprofile user space utility nowadays (since 2012) uses
> > the kernel perf interface instead of the oprofile interface anyway, if
> > present. So the oprofile module itself doesn't seem to have too many users
> > left.
> > 
> > Any opinions?
> 
> yes, the kernel driver is not necessary for oprofile userland for a
> while now. There is no ongoing development any longer, most patches
> are due to changes in the kernel apis.
> 
> So if there is code that needs a larger rework due to other kernel
> changes and there is no user anymore, I am fine with removing the code
> instead of reworking it. I still would just keep existing code as long
> as we can keep it unchanged (some like the lightwight of oprofile,
> esp. in the embedded space). If there is a user of the code, a
> Tested-by would be good for new code changes.
> 
> If there are users of the hwswampler, speak up now. Else, let's just
> remove it.

Ok, so I'll wait a week or so and remove the code if nobody speaks up. Is
it ok for you if I add the patch to the s390 kernel tree?
The patch would only remove s390 specific architecture code.

I have this pending:

    s390/oprofile: remove hardware sampler support
    
    Remove hardware sampler support from oprofile module.
    
    The oprofile user space utilty has been switched to use the kernel
    perf interface, for which we also provide hardware sampling support.
    
    In addition the hardware sampling support is also slightly broken: it
    supports only 16 bits for the pid and therefore would generate wrong
    results on machines which have a pid >64k.
    
    Also the pt_regs structure which was passed to oprofile common code
    cannot necessarily be used to generate sane backtraces, since the
    task(s) in question may run while the samples are fed to oprofile.
    So the result would be more or less random.
    
    However given that the only user space tools switched to the perf
    interface already four years ago the hardware sampler code seems to be
    unused code, and therefore it should be reasonable to remove it.
    
    The timer based oprofile support continues to work.
    
    Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>

 Documentation/kernel-parameters.txt |    2 -
 arch/s390/oprofile/Makefile         |    1 -
 arch/s390/oprofile/hwsampler.c      | 1178 --------------------------------
 arch/s390/oprofile/hwsampler.h      |   63 --
 arch/s390/oprofile/init.c           |  489 -------------
 arch/s390/oprofile/op_counter.h     |   21 -
 6 files changed, 1754 deletions(-)

[toc] | [prev] | [next] | [standalone]

#1421903

On 14.06.16 07:36:08, Heiko Carstens wrote:
> On Mon, Jun 13, 2016 at 06:29:14PM +0200, Robert Richter wrote:
> > Heiko,
> > 
> > On 09.06.16 11:00:56, Heiko Carstens wrote:
> > > However I'm wondering if we shouldn't simply remove at least the s390
> > > specific hwswampler code from the oprofile module. This would still leave
> > > the common code timer based sampling mode for oprofile working on s390.
> > > 
> > > It looks like the oprofile user space utility nowadays (since 2012) uses
> > > the kernel perf interface instead of the oprofile interface anyway, if
> > > present. So the oprofile module itself doesn't seem to have too many users
> > > left.
> > > 
> > > Any opinions?
> > 
> > yes, the kernel driver is not necessary for oprofile userland for a
> > while now. There is no ongoing development any longer, most patches
> > are due to changes in the kernel apis.
> > 
> > So if there is code that needs a larger rework due to other kernel
> > changes and there is no user anymore, I am fine with removing the code
> > instead of reworking it. I still would just keep existing code as long
> > as we can keep it unchanged (some like the lightwight of oprofile,
> > esp. in the embedded space). If there is a user of the code, a
> > Tested-by would be good for new code changes.
> > 
> > If there are users of the hwswampler, speak up now. Else, let's just
> > remove it.
> 
> Ok, so I'll wait a week or so and remove the code if nobody speaks up. Is
> it ok for you if I add the patch to the s390 kernel tree?

Yes, pass it through your tree.

> The patch would only remove s390 specific architecture code.
> 
> I have this pending:
> 
>     s390/oprofile: remove hardware sampler support
>     
>     Remove hardware sampler support from oprofile module.
>     
>     The oprofile user space utilty has been switched to use the kernel
>     perf interface, for which we also provide hardware sampling support.
>     
>     In addition the hardware sampling support is also slightly broken: it
>     supports only 16 bits for the pid and therefore would generate wrong
>     results on machines which have a pid >64k.
>     
>     Also the pt_regs structure which was passed to oprofile common code
>     cannot necessarily be used to generate sane backtraces, since the
>     task(s) in question may run while the samples are fed to oprofile.
>     So the result would be more or less random.
>     
>     However given that the only user space tools switched to the perf
>     interface already four years ago the hardware sampler code seems to be
>     unused code, and therefore it should be reasonable to remove it.
>     
>     The timer based oprofile support continues to work.
>     
>     Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>

Acked-by: Robert Richter <rric@kernel.org>

> 
>  Documentation/kernel-parameters.txt |    2 -
>  arch/s390/oprofile/Makefile         |    1 -
>  arch/s390/oprofile/hwsampler.c      | 1178 --------------------------------
>  arch/s390/oprofile/hwsampler.h      |   63 --
>  arch/s390/oprofile/init.c           |  489 -------------
>  arch/s390/oprofile/op_counter.h     |   21 -
>  6 files changed, 1754 deletions(-)

Could you send the patch for review anyway?

Thanks,

-Robert

[toc] | [prev] | [next] | [standalone]

#1424834

On Tue, Jun 14, 2016 at 05:56:09PM +0200, Heiko Carstens wrote:
> On Tue, Jun 14, 2016 at 03:28:23PM +0200, Robert Richter wrote:
> > > 
> > >  Documentation/kernel-parameters.txt |    2 -
> > >  arch/s390/oprofile/Makefile         |    1 -
> > >  arch/s390/oprofile/hwsampler.c      | 1178 --------------------------------
> > >  arch/s390/oprofile/hwsampler.h      |   63 --
> > >  arch/s390/oprofile/init.c           |  489 -------------
> > >  arch/s390/oprofile/op_counter.h     |   21 -
> > >  6 files changed, 1754 deletions(-)
> > 
> > Could you send the patch for review anyway?
> 
> Yes, of course. I added it below, hope that's ok.
> [I did not yet add your Ack]
> 
> From 74ab0aefe07573358cc6a0c462ddc62ccba4c0cf Mon Sep 17 00:00:00 2001
> From: Heiko Carstens <heiko.carstens@de.ibm.com>
> Date: Fri, 10 Jun 2016 10:40:06 +0200
> Subject: [PATCH] s390/oprofile: remove hardware sampler support
> 
> Remove hardware sampler support from oprofile module.
> 
> The oprofile user space utilty has been switched to use the kernel
> perf interface, for which we also provide hardware sampling support.
> 
> In addition the hardware sampling support is also slightly broken: it
> supports only 16 bits for the pid and therefore would generate wrong
> results on machines which have a pid >64k.
> 
> Also the pt_regs structure which was passed to oprofile common code
> cannot necessarily be used to generate sane backtraces, since the
> task(s) in question may run while the samples are fed to oprofile.
> So the result would be more or less random.
> 
> However given that the only user space tools switched to the perf
> interface already four years ago the hardware sampler code seems to be
> unused code, and therefore it should be reasonable to remove it.
> 
> The timer based oprofile support continues to work.
> 
> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
> ---
>  Documentation/kernel-parameters.txt |    2 -
>  arch/s390/oprofile/Makefile         |    1 -
>  arch/s390/oprofile/hwsampler.c      | 1178 -----------------------------------
>  arch/s390/oprofile/hwsampler.h      |   63 --
>  arch/s390/oprofile/init.c           |  489 ---------------
>  arch/s390/oprofile/op_counter.h     |   21 -
>  6 files changed, 1754 deletions(-)
>  delete mode 100644 arch/s390/oprofile/hwsampler.c
>  delete mode 100644 arch/s390/oprofile/hwsampler.h
>  delete mode 100644 arch/s390/oprofile/op_counter.h
> 

Reviewed-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web