linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] tick/broadcast: Remove redundant code in tick_check_new_device()
@ 2017-11-09  4:54 Zhenzhong Duan
  2017-11-13 16:54 ` Thomas Gleixner
  0 siblings, 1 reply; 4+ messages in thread
From: Zhenzhong Duan @ 2017-11-09  4:54 UTC (permalink / raw)
  To: mingo, tglx, fweisbec; +Cc: Srinivas REDDY Eeda, Joe Jin, linux-kernel

There is no way a timer used as broadcast clockevent device is also used as
percpu tick clockevent device currently.

It's better to put related code in tick_install_broadcast_device(), but I feel
it's harmless to give it back to the clockevents layer. Pls correct me if I'm
wrong.

Signed-off-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>
---
 kernel/time/tick-common.c |    7 +------
 1 files changed, 1 insertions(+), 6 deletions(-)

diff --git a/kernel/time/tick-common.c b/kernel/time/tick-common.c
index 49edc1c..9bcc866 100644
--- a/kernel/time/tick-common.c
+++ b/kernel/time/tick-common.c
@@ -320,13 +320,8 @@ void tick_check_new_device(struct clock_event_device *newdev)
 
 	/*
 	 * Replace the eventually existing device by the new
-	 * device. If the current device is the broadcast device, do
-	 * not give it back to the clockevents layer !
+	 * device.
 	 */
-	if (tick_is_broadcast_device(curdev)) {
-		clockevents_shutdown(curdev);
-		curdev = NULL;
-	}
 	clockevents_exchange_device(curdev, newdev);
 	tick_setup_device(td, newdev, cpu, cpumask_of(cpu));
 	if (newdev->features & CLOCK_EVT_FEAT_ONESHOT)
-- 
1.7.3

^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH] tick/broadcast: Remove redundant code in tick_check_new_device()
  2017-11-09  4:54 [PATCH] tick/broadcast: Remove redundant code in tick_check_new_device() Zhenzhong Duan
@ 2017-11-13 16:54 ` Thomas Gleixner
  2017-11-14  3:29   ` Zhenzhong Duan
  0 siblings, 1 reply; 4+ messages in thread
From: Thomas Gleixner @ 2017-11-13 16:54 UTC (permalink / raw)
  To: Zhenzhong Duan
  Cc: mingo, fweisbec, Srinivas REDDY Eeda, Joe Jin, linux-kernel

On Wed, 8 Nov 2017, Zhenzhong Duan wrote:

> There is no way a timer used as broadcast clockevent device is also used as
> percpu tick clockevent device currently.

Correct.

> It's better to put related code in tick_install_broadcast_device(), but I feel
> it's harmless to give it back to the clockevents layer. Pls correct me if I'm
> wrong.

You already established, that it _cannot_ be the broadcast device and the
per cpu device at the same time. So that condition can never be true. What
do you want to put into tick_install_broadcast_device()? This second
paragraph doesn't make sense, unless I'm missing something.

Thanks,

	tglx

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] tick/broadcast: Remove redundant code in tick_check_new_device()
  2017-11-13 16:54 ` Thomas Gleixner
@ 2017-11-14  3:29   ` Zhenzhong Duan
  2017-11-14 11:39     ` Thomas Gleixner
  0 siblings, 1 reply; 4+ messages in thread
From: Zhenzhong Duan @ 2017-11-14  3:29 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: mingo, fweisbec, Srinivas REDDY Eeda, Joe Jin, linux-kernel

On 2017/11/14 0:54, Thomas Gleixner wrote:

> On Wed, 8 Nov 2017, Zhenzhong Duan wrote:
>
>> There is no way a timer used as broadcast clockevent device is also used as
>> percpu tick clockevent device currently.
> Correct.
>
>> It's better to put related code in tick_install_broadcast_device(), but I feel
>> it's harmless to give it back to the clockevents layer. Pls correct me if I'm
>> wrong.
> You already established, that it _cannot_ be the broadcast device and the
> per cpu device at the same time. So that condition can never be true. What
> do you want to put into tick_install_broadcast_device()? This second
> paragraph doesn't make sense, unless I'm missing something.

I didn't find the reason in long history logs while the comments saying 'If the current device is the broadcast device, do not give it back to the clockevents layer !'

If it does, tick_install_broadcast_device() is a proper place. If not, I can resend the patch with fresh description, pls confirm.

-- 
thanks
zduan

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] tick/broadcast: Remove redundant code in tick_check_new_device()
  2017-11-14  3:29   ` Zhenzhong Duan
@ 2017-11-14 11:39     ` Thomas Gleixner
  0 siblings, 0 replies; 4+ messages in thread
From: Thomas Gleixner @ 2017-11-14 11:39 UTC (permalink / raw)
  To: Zhenzhong Duan
  Cc: mingo, fweisbec, Srinivas REDDY Eeda, Joe Jin, linux-kernel

On Tue, 14 Nov 2017, Zhenzhong Duan wrote:
> On 2017/11/14 0:54, Thomas Gleixner wrote:
> 
> > On Wed, 8 Nov 2017, Zhenzhong Duan wrote:
> > 
> > > There is no way a timer used as broadcast clockevent device is also used
> > > as
> > > percpu tick clockevent device currently.
> > Correct.
> > 
> > > It's better to put related code in tick_install_broadcast_device(), but I
> > > feel
> > > it's harmless to give it back to the clockevents layer. Pls correct me if
> > > I'm
> > > wrong.
> > You already established, that it _cannot_ be the broadcast device and the
> > per cpu device at the same time. So that condition can never be true. What
> > do you want to put into tick_install_broadcast_device()? This second
> > paragraph doesn't make sense, unless I'm missing something.
> 
> I didn't find the reason in long history logs while the comments saying 'If
> the current device is the broadcast device, do not give it back to the
> clockevents layer !'

To be honest I can't figure it out myself why this was put there, even if I
wrote it myself. Fact is that this is wrong and cannot happen at all.

Thanks,

	tglx

 

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2017-11-14 11:40 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-11-09  4:54 [PATCH] tick/broadcast: Remove redundant code in tick_check_new_device() Zhenzhong Duan
2017-11-13 16:54 ` Thomas Gleixner
2017-11-14  3:29   ` Zhenzhong Duan
2017-11-14 11:39     ` Thomas Gleixner

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).