public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Nish Aravamudan <nish.aravamudan@gmail.com>
To: Stas Sergeev <stsp@aknet.ru>
Cc: john stultz <johnstul@us.ibm.com>,
	Linux kernel <linux-kernel@vger.kernel.org>
Subject: Re: [rfc][patch] API for timer hooks
Date: Tue, 16 Aug 2005 15:24:34 -0700	[thread overview]
Message-ID: <29495f1d0508161524260a856c@mail.gmail.com> (raw)
In-Reply-To: <43024ADA.8030508@aknet.ru>

On 8/16/05, Stas Sergeev <stsp@aknet.ru> wrote:
> Hello.
> 
> john stultz wrote:
> > Interesting. Could you explain why the soft-timer interface doesn't<>
> > suffice?
> I'll try to explain why *I think*
> it doesn't suffice, please correct
> me if my assumptions are wrong.
> 
> There are two (bad) things about the
> PC-Speaker driver:
> 1. It needs the higher interrupt frequency.
> Since there seem to be no API to change
> the timer frequency at runtime, the driver
> does this itself. Now I have googled out
> the thread
> [PATCH] i386: Selectable Frequency of the Timer Interrupt
> but it doesn't look like it ended up
> with some patch applied, or where is it?

This thread resulted in CONFIG_HZ. You get to choose between 100, 250
or 1000. It was not meant to allow runtime HZ modifications.

> 2. It needs its handler to be executed
> first in the chain. Otherwise the quality
> is poor because of the latency.

Yeah, that's a tougher one :)

> My approach solves both problems by
> introducing the grabbing ability.
> This is a rather simple patch, and since
> it allows to do some cleanup, I though
> it could be usefull not only for the
> speaker driver.
> But if you can tell me how to achieve
> at least the point 1 (that is, speed up the
> timer at run-time quite arbitrary) without
> the kernel mods, then it would be a real
> salvation.

Does the dynamic-tick patch help you at all? I'm not sure if it's
meant to, admittedly. I'm also not sure if it has any cap on the
maximum HZ it attempts to reprogram the hardware to... Mucking with HZ
at run-time is going to break lots of stuff, though...well, not
necessarily, depends on how you muck with jiffies :)

Thanks,
Nish

  reply	other threads:[~2005-08-16 22:24 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-13 13:36 [rfc][patch] API for timer hooks Stas Sergeev
2005-08-15 17:19 ` john stultz
2005-08-16 20:21   ` Stas Sergeev
2005-08-16 22:24     ` Nish Aravamudan [this message]
2005-08-17 16:10       ` Stas Sergeev
2005-08-17  2:09     ` Lee Revell
2005-08-17 16:21       ` Stas Sergeev
2005-08-17 16:40         ` Lee Revell
2005-08-17 17:41           ` Stas Sergeev
2005-08-17 23:16             ` Lee Revell
2005-08-18 16:59               ` Stas Sergeev
2005-08-18 17:07                 ` Lee Revell

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=29495f1d0508161524260a856c@mail.gmail.com \
    --to=nish.aravamudan@gmail.com \
    --cc=johnstul@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stsp@aknet.ru \
    /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