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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ