linux-kernel - Re: [PATCH] ARM: convert arm/arm64 arch timer to use CLKSRC

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] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 21 Mar 2013 11:35:49 +0000
From:	Marc Zyngier <marc.zyngier@....com>
To:	Mark Rutland <mark.rutland@....com>
CC:	Rob Herring <robherring2@...il.com>,
	Simon Horman <horms@...ge.net.au>,
	Kukjin Kim <kgene.kim@...sung.com>,
	Russell King <linux@....linux.org.uk>,
	Arnd Bergmann <arnd@...db.de>,
	"linux-sh@...r.kernel.org" <linux-sh@...r.kernel.org>,
	Tony Lindgren <tony@...mide.com>,
	Catalin Marinas <Catalin.Marinas@....com>,
	Magnus Damm <magnus.damm@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"rob.herring@...xeda.com" <rob.herring@...xeda.com>,
	"linux-samsung-soc@...r.kernel.org" 
	<linux-samsung-soc@...r.kernel.org>,
	John Stultz <john.stultz@...aro.org>,
	Will Deacon <Will.Deacon@....com>,
	Thomas Gleixner <tglx@...utronix.de>,
	"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] ARM: convert arm/arm64 arch timer to use CLKSRC_OF init

On 21/03/13 11:06, Mark Rutland wrote:
> Hi Rob,
> 
> (adding Marc to Cc as he may have comments).
> 
> On Wed, Mar 20, 2013 at 10:34:35PM +0000, Rob Herring wrote:
>> From: Rob Herring <rob.herring@...xeda.com>
>>
>> This converts arm and arm64 to use CLKSRC_OF DT based initialization for
>> the arch timer. A new function arch_timer_arch_init is added to allow for
>> arch specific setup.
>>
>> This has a side effect of enabling sched_clock on omap5 and exynos5. There
>> should not be any reason not to use the arch timers for sched_clock.
> 
> Nice! I was just about to post a (slightly updated) version of Thomas Abraham's
> arch_timer clocksource_of_init patch, but this seems much more comprehensive.
> 
> I have some other arch_timer patches which may clash, but they could be rebased
> atop of this.
> 
>>
>> Signed-off-by: Rob Herring <rob.herring@...xeda.com>
>> Cc: Russell King <linux@....linux.org.uk>
>> Cc: Kukjin Kim <kgene.kim@...sung.com>
>> Cc: Tony Lindgren <tony@...mide.com>
>> Cc: Simon Horman <horms@...ge.net.au>
>> Cc: Magnus Damm <magnus.damm@...il.com>
>> Cc: Catalin Marinas <catalin.marinas@....com>
>> Cc: Will Deacon <will.deacon@....com>
>> Cc: John Stultz <john.stultz@...aro.org>
>> Cc: Thomas Gleixner <tglx@...utronix.de>
>> Cc: linux-samsung-soc@...r.kernel.org
>> Cc: linux-omap@...r.kernel.org
>> Cc: linux-sh@...r.kernel.org
>> ---
>> This is dependent on my CLKSRC_OF clean-up in arm-soc, my 64-bit sched_clock
>> support series, and Arnd's default machine descriptor patch (for default
>> clocksource_of_init call). This is only compile tested on arm.
>>
>> The full series (including sp804 work) is available here:
>> git://sources.calxeda.com/kernel/linux.git arm-timers
>>
>> Rob
>>
> 
> [...]
> 
>> diff --git a/arch/arm/mach-vexpress/v2m.c b/arch/arm/mach-vexpress/v2m.c
>> index d0ad789..6215717 100644
>> --- a/arch/arm/mach-vexpress/v2m.c
>> +++ b/arch/arm/mach-vexpress/v2m.c
>> @@ -1,6 +1,7 @@
>>  /*
>>   * Versatile Express V2M Motherboard Support
>>   */
>> +#include <linux/clocksource.h>
>>  #include <linux/device.h>
>>  #include <linux/amba/bus.h>
>>  #include <linux/amba/mmci.h>
>> @@ -23,7 +24,6 @@
>>  #include <linux/regulator/machine.h>
>>  #include <linux/vexpress.h>
>>
>> -#include <asm/arch_timer.h>
>>  #include <asm/mach-types.h>
>>  #include <asm/sizes.h>
>>  #include <asm/mach/arch.h>
>> @@ -446,10 +446,7 @@ static void __init v2m_dt_timer_init(void)
>>                                 irq_of_parse_and_map(node, 0));
>>         }
>>
>> -       arch_timer_of_register();
>> -
>> -       if (arch_timer_sched_clock_init() != 0)
>> -               versatile_sched_clock_init(vexpress_get_24mhz_clock_base(),
>> +       versatile_sched_clock_init(vexpress_get_24mhz_clock_base(),
>>                                 24000000);
>>  }
>>
> 
> On TC2 this series leads to using the vexpress 24MHz clock as the sched clock
> in preference to the architected timer:
> 
>   Architected local timer running at 24.00MHz (virt).
>   Switching to timer-based delay loop
>   Registered arch_counter_get_cntvct+0x0/0x14 as sched_clock source
>   sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms
>   Registered versatile_read_sched_clock+0x0/0x28 as sched_clock source
> 
> As they both have the same frequency, neither overrides the other, and
> whichever gets registered last is used as the sched_clock. As accesses to the
> architected timer are going to have a much lower overhead, this isn't very nice
> (and it could be better to use it even if it had a lower frequency).

Indeed. And if I look at it with my KVM hat on, it is even worse (the
guest will exit all the way to platform emulation in userspace on each
sched_clock read - a sure performance killer).

Of course, emulating a VE is not the best option, but that's all we have
so far when using QEMU as platform emulation.

	M.
-- 
Jazz is not dead. It just smells funny...

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