From: Andreas Mohr <andi@lisas.de>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Andreas Mohr <andi@lisas.de>,
Venki Pallipadi <venkatesh.pallipadi@intel.com>,
linux-kernel@vger.kernel.org, shaohua.li@intel.com
Subject: Re: [PATCH] Prevent clockevent event_handler ending up handler_noop
Date: Thu, 4 Sep 2008 10:15:35 +0200 [thread overview]
Message-ID: <20080904081535.GA593@rhlx01.hs-esslingen.de> (raw)
In-Reply-To: <alpine.LFD.1.10.0809032058380.3243@apollo.tec.linutronix.de>
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
next prev parent reply other threads:[~2008-09-04 8:15 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-02 23:20 Venki Pallipadi
2008-09-02 23:31 ` Thomas Gleixner
2008-09-03 16:43 ` Andreas Mohr
2008-09-03 17:15 ` Thomas Gleixner
2008-09-03 17:36 ` Andreas Mohr
2008-09-03 19:01 ` Thomas Gleixner
2008-09-04 8:15 ` Andreas Mohr [this message]
2008-09-04 8:27 ` Thomas Gleixner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080904081535.GA593@rhlx01.hs-esslingen.de \
--to=andi@lisas.de \
--cc=linux-kernel@vger.kernel.org \
--cc=shaohua.li@intel.com \
--cc=tglx@linutronix.de \
--cc=venkatesh.pallipadi@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®