linux-kernel - Re: [PATCHv3 01/10] clocksource: add generic dummy timer driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <515E2CF1.6030709@codeaurora.org>
Date:	Thu, 04 Apr 2013 18:46:25 -0700
From:	Stephen Boyd <sboyd@...eaurora.org>
To:	Mark Rutland <mark.rutland@....com>
CC:	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>,
	John Stultz <john.stultz@...aro.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Santosh Shilimkar <santosh.shilimkar@...com>
Subject: Re: [PATCHv3 01/10] clocksource: add generic dummy timer driver

On 03/26/13 04:28, Mark Rutland wrote:
> On Tue, Mar 26, 2013 at 02:14:53AM +0000, Stephen Boyd wrote:
>> Ok. Thanks for clearing up my confusion.
>>
>> Like you say, increasing the dummy timer rating seems like a hack. But
>> it also sounds like you want to keep the dummy timer driver fully self
>> contained. I'm not opposed to calling dummy_timer_register() at the
>> bottom of tick_init() if we have to, but it sounds like you don't like that.
> I'd like to keep the dummy timer driver self-contained if we can, but if it
> makes it more robust and/or easier to deal with by having an external call to
> register the driver, then I'm not opposed to that.
>
>> An alternative would be to push the dummy timer logic into the core
>> clockevents layer under the ifdef for arch has broadcast. This is
>> probably the correct approach because most devices don't want to have a
>> dummy timer sitting around unused. I might be able to take a look at
>> this tomorrow.
> I'm also not opposed to this idea.

What if we only check the rating if the two devices are for the same
CPU, i.e. always prefer percpu devices over global ones? This would make
your dummy timers into tick devices.

diff --git a/kernel/time/tick-common.c b/kernel/time/tick-common.c
index b1600a6..9ea59b9 100644
--- a/kernel/time/tick-common.c
+++ b/kernel/time/tick-common.c
@@ -251,9 +251,10 @@ static int tick_check_new_device(struct clock_event_device *newdev)
                    !(newdev->features & CLOCK_EVT_FEAT_ONESHOT))
                        goto out_bc;
                /*
-                * Check the rating
+                * Check the rating, but prefer CPU local devices
                 */
-               if (curdev->rating >= newdev->rating)
+               if (curdev->rating >= newdev->rating &&
+                   cpumask_equal(curdev->cpumask, newdev->cpumask))
                        goto out_bc;
        }
 

I think it will work with smp_twd, sp804, and dummy timers registered in
any order too.

> Though "broadcasting" to the same cpu is special-cased in tick_do_broadcast,
> which will call the tick device's event_handler directly rather than having the
> cpu attempt to IPI to itself.
>
> As you suggest, tick_switch_to_oneshot does complain:
>
> Clockevents: could not switch to one-shot mode: dummy_timer is not functional.
> Could not switch to high resolution mode on CPU 0
>
> To handle this case we could check cpu_possible_mask when initialising the
> dummy and only register it if more than 1 cpu is possible. That would be
> roughly in line with how we handle this case in smp.c.

Yes, this will work well enough. Squashed it into this patch.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/