linux-kernel - Re: [PATCH] Prevent clockevent event_handler ending up handler

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20080904081535.GA593@rhlx01.hs-esslingen.de>
Date:	Thu, 4 Sep 2008 10:15:35 +0200
From:	Andreas Mohr <andi@...as.de>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	Andreas Mohr <andi@...as.de>,
	Venki Pallipadi <venkatesh.pallipadi@...el.com>,
	linux-kernel@...r.kernel.org, shaohua.li@...el.com
Subject: Re: [PATCH] Prevent clockevent event_handler ending up handler_noop

Hi,

On Wed, Sep 03, 2008 at 09:01:35PM +0200, Thomas Gleixner wrote:
> When you register something better than PIT, then the PIT is
> disabled completely. No more interrupts from there.

GOOD.

> > Out of interest: how big would you believe the benefit to be?
> > (overall system performance gains and ACPI PM benefits)
> 
> Hard to tell, your milage can vary.

ACPI PM benefits exclusively depend on whether I can make my system go
below 20 wakeups/s at all or not, otherwise there won't be any improvement
of course.

I/O overhead due to PIT ISA access _might_ be a couple % of overall
system performance, but as you say, this is hard to tell, admittedly.

We'll see rather soon, since integration is finished, however I get
MODPOST symbol link errors for clockevents_register_device() and another
clockevent function which I forgot.
Most certainly we should have had an EXPORT_SYMBOL_GPL() for
these? Or are you going to tell me that modular registration won't work
at all (yet?) for clock_event_device, as opposed to clocksource?

Anything else I need to take into account, other than applying the
fixup patch in the parent post and exporting these symbols?
And how to unregister the event device on module unload?

Oh, and another question:
Since this timer hardware was previously hooked up to an ALSA snd_timer
(struct snd_timer_hardware), do you think changing this into
clock_event_device provides almost equivalent service quality?
snd_timer is used for precise MIDI timestamping (and not much else,
thus this valuable timer was entirely unused/idle, read: wasted), I think,
so I wonder what kind of accuracy loss (jitter, additional timer/IRQ load)
I'd have for MIDI operation if I used this timer for the entire system's
highres timer wheel. If you believe this is even remotely comparably robust
as using a snd_timer-only construct, then I'm more than happy to rip out
snd_timer and _always_ go with clock_event_device instead.

Looking forward to getting my box crashed, hard ;)

Thanks!

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