linux-kernel - [PATCH 0/3] Convert acked !GENERIC_TIME architectures to use the generic timekeeping core.

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-next>] [day] [month] [year] [list]

Message-Id: <1234312149.7801.26.camel@localhost>
Date:	Tue, 10 Feb 2009 16:29:09 -0800
From:	john stultz <johnstul@...ibm.com>
To:	lkml <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Cc:	rmk+lkml@....linux.org.uk, cooloney@...nel.org, starvik@...s.com,
	takata@...ux-m32r.org, geert@...ux-m68k.org,
	Roman Zippel <zippel@...ux-m68k.org>, lethal@...ux-sh.org,
	Magnus Damm <magnus.damm@...il.com>, wli@...omorphy.com,
	chris@...kel.net, Thomas Gleixner <tglx@...utronix.de>
Subject: [PATCH 0/3] Convert acked !GENERIC_TIME architectures to use the
 generic timekeeping core.

Andrew, All,

	Its been two and a half years since the GENERIC_TIME infrastructure
landed. It allowed architectures that have free running counters to only
have to provide a clocksource driver and leave the rest of the
timekeeping management to generic code.

So far out of the 23 architectures we've fully converted 15 of them over
to GENERIC_TIME. The remaining 8 have in some cases been able to
convert, but not fully. The issue that keeps most architectures from
converting is that they do not have free running counters. They instead
use the counter on their tick timer to determine their inter-tick time.
This counter usually wraps every interrupt, so its not really efficient
to use as a clocksource.

This has created some difficulty as the generic timekeeping core has had
to deal with both GENERIC_TIME arches as well as !GENERIC_TIME arches,
and since it didn't manage 100% of the calculation in the !GENERIC_TIME
case, we've been limited in some of the changes we could make.

So since these last remaining architectures are unlikely to be able to
fully convert to GENERIC_TIME as it stands, the generic core should try
to adopt to their needs so we can bring them into the fold and reduce
code duplication.

The solution is to provide a arch callout from the generic timekeeping
core: arch_gettimeoffset().  On architectures that do not provide a
clocksource, the jiffies clocksource is used, and arch_gettimeoffset is
added in to create finer grained inter-tick time.

The patchset I'm submitting does the following:
1) Introduces the arch_gettimeoffset infrastructure to the timekeeping
core.
2) Converts two Acked arches (sh, sparc) to use the arch_gettimeoffset()
hook.

I still have patches for the 6 other arches that need to be converted,
but have not received acks for them yet. Instead of stalling the
patchset for all of those arches, I'm submitting these, so overloaded
arch maintainers can convert their arches or take my patches on their
schedule without blocking arches that are ready to go.

Once all 8 arches are converted, I'll send a final cleanup patch that
removes all conditionals and references to GENERIC_TIME.

Credits to Roman for initially suggesting the idea quite awhile back.

thanks
-john

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