s390/oprofile: Remove deprecated create_workqueue

A dedicated workqueue has been used since the workqueue hws_wq with workitem &cb->worker, is involved in hardware based sampling on System z processors.

Since, these are long-running work items and aren't involved in memory reclaim in any way, system_long_wq has been used.

Signed-off-by Bhaktipriya Shridhar <[email protected]>

---
 arch/s390/oprofile/hwsampler.c | 21 +++------------------
 1 file changed, 3 insertions(+), 18 deletions(-)

arch/s390/oprofile/hwsampler.c +0 -8

-		if (hws_wq)
-			flush_workqueue(hws_wq);
-
 		mutex_lock(&hws_sem);
 
 		if (hws_state == HWS_STOPPED) {

@@ -1059,10 +1048,6 @@ int hwsampler_shutdown(void)
 			hws_alert = 0;
 			deallocate_sdbt();
 		}
-		if (hws_wq) {
-			destroy_workqueue(hws_wq);
-			hws_wq = NULL;
-		}
 
 		unregister_external_irq(EXT_IRQ_MEASURE_ALERT, hws_ext_handler);
 		hws_state = HWS_INIT;
--

2.1.4

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?

Heiko,

Quoted 10 lines · Heiko Carstens

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

Heiko,

Quoted 10 lines · Heiko Carstens

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.

Quoted 25 lines · Robert Richter

Heiko,

Quoted 10 lines · Heiko Carstens

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.

Quoted 2 lines

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 <[email protected]>

 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(-)

Quoted 8 lines

 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?

Quoted 10 lines · Robert Richter

Quoted 8 lines

 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 <[email protected]>
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 <[email protected]>

---
 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