linux-kernel - Re: sparc generic time / clockevents

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]

Message-Id: <20070223.163428.104033815.davem@davemloft.net>
Date:	Fri, 23 Feb 2007 16:34:28 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	johnstul@...ibm.com
Cc:	tglx@...utronix.de, linux-kernel@...r.kernel.org,
	peter.keilty@...com
Subject: Re: sparc generic time / clockevents

From: john stultz <johnstul@...ibm.com>
Date: Fri, 23 Feb 2007 11:51:18 -0800

> Yea. I actually have some in-progress patches from Peter Keilty that
> convert ia64 and sparc64 time_interpolators to clocksources, then
> removes the time_interpolator code.
> 
> The ia64 conversion is more complicated due to the fsyscall asm, but I
> think the sparc64 conversion (below) is pretty straight forward. I've
> only built tested this, so I have no clue if it actually works. 
> 
> Any thoughts?

Hey John, I had to do this already in order to do the dynticks
port to sparc64, but nice to see another attempt :-)

Two things I did on my side:

+	.mask           = 0xffffffffffffffffLL,

I used CLOCKSOURCE_MASK(64) here.

+static cycle_t read_sparc64_cpuclock(void)
+{
+        return (cycle_t)get_cycles();
+}
 ...
+	.read           = read_sparc64_cpuclock,

You can just directly assign tick_ops->get_tick to .read at run-time
to avoid a stack frame and function call/return.

+	.shift          = 16,

These shift selections all seem rather arbitrary.

If it's not an arbitrary selection, it would be nice to have some
comments about how to go about choosing an appropriate shift.
I imagine the selections has to do with the possible range of
the frequencies the clocksource supports, and how much
accuracy you get for certain shift selections given that range.
-
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/