On Sat, Jul 23, 2005 at 04:40:46PM -0700, randy_dunlap wrote:
> On Sat, 16 Jul 2005 23:55:17 -0400 Lee Revell wrote:
>
> > On Sat, 2005-07-16 at 19:35 -0700, Nish Aravamudan wrote:
> > > As you've seen, I think it depends on the timesource: for the PIT, it
> > > would be arch/i386/kernel/timers/t
Jesper Juhl wrote:
On 7/24/05, randy_dunlap <[EMAIL PROTECTED]> wrote:
On Fri, 15 Jul 2005 05:46:44 +0200 Jesper Juhl wrote:
+static int __init jiffies_increment_setup(char *str)
+{
+ printk(KERN_NOTICE "setting up jiffies_increment : ");
+ if (str) {
+ printk("ker
On 7/24/05, randy_dunlap <[EMAIL PROTECTED]> wrote:
> On Fri, 15 Jul 2005 05:46:44 +0200 Jesper Juhl wrote:
>
> > +static int __init jiffies_increment_setup(char *str)
> > +{
> > + printk(KERN_NOTICE "setting up jiffies_increment : ");
> > + if (str) {
> > + printk("kernel_hz =
On Fri, 15 Jul 2005 05:46:44 +0200 Jesper Juhl wrote:
> +static int __init jiffies_increment_setup(char *str)
> +{
> + printk(KERN_NOTICE "setting up jiffies_increment : ");
> + if (str) {
> + printk("kernel_hz = %s, ", str);
> + } else {
> + printk("kernel_hz i
On Sat, 16 Jul 2005 23:55:17 -0400 Lee Revell wrote:
> On Sat, 2005-07-16 at 19:35 -0700, Nish Aravamudan wrote:
> > As you've seen, I think it depends on the timesource: for the PIT, it
> > would be arch/i386/kernel/timers/timer_pit.c::setup_pit_timer().
>
> That one looks pretty straightforwar
On Fri, 15 Jul 2005, Venkatesh Pallipadi wrote:
> Well.. I tried a patch to do the broadcast thing couple of months ago and
> failed to convince everyone :(.
I must have missed the patch -- but was the change unconditional or
affecting only broken systems? And how such systems were determined
On Fri, 15 Jul 2005, Andi Kleen wrote:
> > That's like scratching your left ear with your right hand -- broadcasting
> > that external timer interrupt in the first place is more straightforward.
> > If you want to exclude CPUs from the list of receivers, just use the
> > logical destination m
On Thu, Jul 14, 2005 at 04:25:12PM +0200, Peter Osterlund wrote:
> Linus Torvalds <[EMAIL PROTECTED]> writes:
>
> > On Wed, 13 Jul 2005, Jan Engelhardt wrote:
> > >
> > > No, some kernel code causes a triple-fault-and-reboot when the HZ is >=
> > > 10KHz. Maybe the highest possible value is 8192
On Sat, 2005-07-16 at 19:35 -0700, Nish Aravamudan wrote:
> As you've seen, I think it depends on the timesource: for the PIT, it
> would be arch/i386/kernel/timers/timer_pit.c::setup_pit_timer().
That one looks pretty straightforward.
arch/i386/kernel/timers/timer_tsc.c really looks like fun. S
On 7/16/05, Jesper Juhl <[EMAIL PROTECTED]> wrote:
> On 7/15/05, Jesper Juhl <[EMAIL PROTECTED]> wrote:
> > On 7/15/05, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > >
> > > On Fri, 15 Jul 2005, Jesper Juhl wrote:
> > > >
> > > > It's buggy, that I know. setting kernel_hz (the new boot parameter) t
On Sun, 2005-07-17 at 04:13 +0200, Jesper Juhl wrote:
> Where do we actually program the tick rate we want?
>
In arch/i386/kernel/timers/timer_pit.c:
166 void setup_pit_timer(void)
167 {
168 unsigned long flags;
169
170 spin_lock_irqsave(&i8253_lock, flags);
On 7/15/05, Jesper Juhl <[EMAIL PROTECTED]> wrote:
> On 7/15/05, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> >
> > On Fri, 15 Jul 2005, Jesper Juhl wrote:
> > >
> > > It's buggy, that I know. setting kernel_hz (the new boot parameter) to
> > > 250 causes my system clock to run at something like 4-5
Hi!
> > The real answer here is for the tickless patches to cleaned up to
> > the point where they can be merged, and then we won't waste battery
> > power entering the timer interrupt in the first place. :-)
>
> Whilst conceptually this is a nice idea I've yet to see any viable
> code that over
Hi!
> > Alan tested it and said that 250HZ does not save much power anyway.
>
> Len Brown, a year ago: "The bottom line number to laptop users is battery
> lifetime. Just today somebody complained to me that Windows gets twice the
> battery life that Linux does."
>
> And "Maybe I can get Andy G
On Fri, 2005-07-15 at 12:58 -0700, Stephen Pollei wrote:
> But If I understand Linus's points he wants jiffies to remain a memory
> fetch, and make sure it doesn't turn into a singing dancing christmas
> tree.
It seems it relatively easy to support dynamic tick, the ARM
architecture has it. But wi
On 7/14/05, Eric St-Laurent <[EMAIL PROTECTED]> wrote:
> On Thu, 2005-07-14 at 17:24 -0700, Linus Torvalds wrote:
> > Trust me. When I say that the right thing to do is to just have a fixed
> > (but high) HZ value, and just changing the timer rate, I'm -right-.
> Of course you are, jiffies are sim
On Fri, Jul 15, 2005 at 07:57:01PM +0200, Andi Kleen wrote:
> > I wouldn't say it is totally impossible. There are ways in which Linux can
> > work
> > without a reliable Local APIC timer. One option being - make one CPU that
> > gets
> > the external timer interrupt multicast an IPI to all the
On Fri, Jul 15, 2005 at 06:54:30PM +0100, Maciej W. Rozycki wrote:
> On Fri, 15 Jul 2005, Venkatesh Pallipadi wrote:
>
> > I wouldn't say it is totally impossible. There are ways in which Linux can
> > work
> > without a reliable Local APIC timer. One option being - make one CPU that
> > gets
>
> That's like scratching your left ear with your right hand -- broadcasting
> that external timer interrupt in the first place is more straightforward.
> If you want to exclude CPUs from the list of receivers, just use the
> logical destination mode appropriately.
The problem with that is tha
> I wouldn't say it is totally impossible. There are ways in which Linux can
> work
> without a reliable Local APIC timer. One option being - make one CPU that
> gets
> the external timer interrupt multicast an IPI to all the other CPUs that
> wants to get periodic timer interrupt.
That doesn't
On Fri, 15 Jul 2005, Venkatesh Pallipadi wrote:
> I wouldn't say it is totally impossible. There are ways in which Linux can
> work
> without a reliable Local APIC timer. One option being - make one CPU that
> gets
> the external timer interrupt multicast an IPI to all the other CPUs that
> wan
On Fri, Jul 15, 2005 at 07:02:24PM +0200, Andi Kleen wrote:
>
> At least on multi processor systems LAPIC has to work anyways (otherwise
> you cannot schedule other CPUs), so it is fine to use there.
>
> AFAIK there are no x86 CPUs right now that do both C3
> and SMP. If they ever do then they wi
Quoting Lee Revell <[EMAIL PROTECTED]>:
> On Thu, 2005-07-14 at 22:54 -0600, Zwane Mwaikambo wrote:
> > On Fri, 15 Jul 2005, Lee Revell wrote:
> >
> > > On Fri, 2005-07-15 at 14:08 +1000, Con Kolivas wrote:
> > > > Audio did show slightly larger max latencies but nothing that would be
> of
> > >
"Brown, Len" <[EMAIL PROTECTED]> writes:
> >That's an APIC bug.
> >When Intel originally released the APIC (some
> >thirteen years ago) they stated it should be used as a source of the
> timer
> >interrupt instead of the 8254. There is no excuse for changing the
> >behaviour after so many years.
On Thu, 2005-07-14 at 22:54 -0600, Zwane Mwaikambo wrote:
> On Fri, 15 Jul 2005, Lee Revell wrote:
>
> > On Fri, 2005-07-15 at 14:08 +1000, Con Kolivas wrote:
> > > Audio did show slightly larger max latencies but nothing that would be of
> > > significance.
> > >
> > > On video, maximum latenci
On Fri, Jul 15, 2005 at 12:33:15PM -0400, Brown, Len wrote:
> So, the 13-year-old design advice will continue to apply to
> 13-year-old systems, but newer systems with C3 and HPET
> should be using them.
Last I looked HPET isn't everywhere yet (absent from nforce4
mainboards for example, but that
On Fri, 2005-07-15 at 05:46, Bill Davidsen wrote:
> Fernando Lopez-Lezcano wrote:
> >On Thu, 2005-07-14 at 16:49, Linus Torvalds wrote:
> >>On Thu, 14 Jul 2005, Lee Revell wrote:
> >>>And I'm incredibly frustrated by this insistence on hard data when it's
> >>>completely obvious to anyone who knows
>That's an APIC bug.
>When Intel originally released the APIC (some
>thirteen years ago) they stated it should be used as a source of the
timer
>interrupt instead of the 8254. There is no excuse for changing the
>behaviour after so many years. So if you are on a broken system, you
may
>want to wo
On Fri, 2005-07-15 at 08:57 -0700, Christoph Lameter wrote:
> Try HPET which is pretty standard these days.
>
Really? None of my machines have it. I suspect lots of "embeddable"
systems don't either.
Lee
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
On Fri, 15 Jul 2005, Paul Jakma wrote:
> On Thu, 14 Jul 2005, Christoph Lameter wrote:
>
> > Linux can already provide a response time within < 3 usecs from user space
> > using f.e. the Altix RTC driver which can generate an interrupt that then
> > sends a signal to an application. The Altix RTC
On 7/15/05, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
> On Fri, 15 Jul 2005, Jesper Juhl wrote:
> >
> > It's buggy, that I know. setting kernel_hz (the new boot parameter) to
> > 250 causes my system clock to run at something like 4-5 times normal
> > speed
>
> 4 times normal. You don't actuall
Fernando Lopez-Lezcano wrote:
On Thu, 2005-07-14 at 16:49, Linus Torvalds wrote:
On Thu, 14 Jul 2005, Lee Revell wrote:
And I'm incredibly frustrated by this insistence on hard data when it's
completely obvious to anyone who knows the first thing about MIDI that
HZ=250 will fail in sit
On Gwe, 2005-07-15 at 00:19, Linus Torvalds wrote:
> That's not what "jiffies" are about. If you want accurate time, use
> something else, like gettimeofday. The timeouts are _only_ relevant on the
> scale of a timer interrupt, since by definition that's what we're waiting
> for.
Ok makes sense -
Lee Revell wrote:
On Thu, 2005-07-14 at 16:49 -0700, Linus Torvalds wrote:
YOUR argument is "nobody else matters, only I do".
MY argument is that this is a case of give and take.
I wouldn't say that. I do agree with you that HZ=1000 for everyone is
problematic, I just feel that a r
On Thu, 14 Jul 2005, Christoph Lameter wrote:
Linux can already provide a response time within < 3 usecs from
user space using f.e. the Altix RTC driver which can generate an
interrupt that then sends a signal to an application. The Altix RTC
clock is supported via POSIX timer syscalls and can
On Thu, 14 Jul 2005, Brown, Len wrote:
> >Of course using APIC internal timers is generally the best idea on SMP,
> >but they may have had reasons to avoid them (it's not an ISA interrupt,
> so
> >it could have been simply out of question in the initial design).
>
> Best? No.
>
> Local APIC tim
Hi, Bill Davidsen wrote:
> Do you actually have something against tickless, or just don't think it
> can be done in reasonable time?
You can do it in small steps.
When you have that jiffies_increment variable, you can add code to
dynamically adjust it at runtime -- just reprogram the system tim
On Thu, Jul 14, 2005 at 05:24:39PM -0700, Linus Torvalds wrote:
> HOWEVER. I bet that somebody who really really cares (hint hint) could
> easily make HZ be 1000, and then dynamically tweak the divisor at bootup
> to be either 1000, 250, or 100, and then increment "jiffies" by 1, 4 or
> 10.
Wouldn
On Thu, Jul 14, 2005 at 05:42:15PM -0700, Linus Torvalds wrote:
> So this is why I so strongly argue that we should have a constant HZ, but
> a dynamic _increment_ of "jiffies". Nobody (obviously) depends on jiffies
> being constant, so it's ok to increment jiffies by pretty much any value.
I ag
Linus Torvalds <[EMAIL PROTECTED]> writes:
> Now, if somebody wants to make nicer helper functions so that you can say
>
> timeout = ms_from_now(500);
We already have something very simliar:
timeout = jiffies + msecs_to_jiffies(500);
;)
Gerd
--
panic("it works"); /* avoid bei
On Fri, 15 Jul 2005, Jesper Juhl wrote:
>
> It's buggy, that I know. setting kernel_hz (the new boot parameter) to
> 250 causes my system clock to run at something like 4-5 times normal
> speed
4 times normal. You don't actually make the timer interrupt happen at
250Hz, so the timer will be p
On Fri, 15 Jul 2005, Lee Revell wrote:
> On Fri, 2005-07-15 at 14:08 +1000, Con Kolivas wrote:
> > Audio did show slightly larger max latencies but nothing that would be of
> > significance.
> >
> > On video, maximum latencies are only slightly larger at HZ 250, all the
> > desired cpu was achi
On Fri, 2005-07-15 at 14:08 +1000, Con Kolivas wrote:
> Audio did show slightly larger max latencies but nothing that would be of
> significance.
>
> On video, maximum latencies are only slightly larger at HZ 250, all the
> desired cpu was achieved, but the average latency and number of missed
On Fri, 15 Jul 2005 09:25, Linus Torvalds wrote:
> On Thu, 14 Jul 2005, Lee Revell wrote:
> > On Thu, 2005-07-14 at 09:37 -0700, Linus Torvalds wrote:
> > > I have to say, this whole thread has been pretty damn worthless in
> > > general in my not-so-humble opinion.
> >
> > This thread has really g
Linus Torvalds wrote:
On Thu, 14 Jul 2005, Lee Revell wrote:
I don't think this will fly because we take a big performance hit by
calculating HZ at runtime.
I think it might be an acceptable solution for a distribution that really
needed it, since it should be fairly simple. However, it's
On Thu, 2005-07-14 at 16:49, Linus Torvalds wrote:
> On Thu, 14 Jul 2005, Lee Revell wrote:
> >
> > And I'm incredibly frustrated by this insistence on hard data when it's
> > completely obvious to anyone who knows the first thing about MIDI that
> > HZ=250 will fail in situations where HZ=1000 su
Linus Torvalds wrote:
On Thu, 14 Jul 2005, Lee Revell wrote:
I don't think this will fly because we take a big performance hit by
calculating HZ at runtime.
I think it might be an acceptable solution for a distribution that really
needed it, since it should be fairly simple. However,
On Thu, 2005-07-14 at 17:24 -0700, Linus Torvalds wrote:
>
> On Thu, 14 Jul 2005, Lee Revell wrote:
>
> Trust me. When I say that the right thing to do is to just have a fixed
> (but high) HZ value, and just changing the timer rate, I'm -right-.
>
> I'm always right. This time I'm just even mor
On 7/15/05, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Thu, 14 Jul 2005, Lee Revell wrote:
> >
> > I don't think this will fly because we take a big performance hit by
> > calculating HZ at runtime.
>
> I think it might be an acceptable solution for a distribution that really
> needed it
On Thu, 2005-07-14 at 23:37 +0100, Alan Cox wrote:
> In actual fact you also want to fix users of
>
> while(time_before(foo, jiffies)) { whack(mole); }
>
> to become
>
> init_timeout(&timeout);
> timeout.expires = jiffies + n
> add_timeout(&timeout);
> while(!timeo
David Lang wrote:
On Wed, 13 Jul 2005, Bill Davidsen wrote:
How serious is the 1/HZ = sane problem, and more to the point how
many programs get the HZ value with a system call as opposed to
including a header or building it in? I know some of my older
programs use header files, that was part
On Fri, 15 Jul 2005, Jesper Juhl wrote:
>
> Even if we only have to do it once at boot? The thought was to detect
> what type of machine we are booting on, figure out what a good HZ
> would be for that type of box, then set that HZ value and treat it as
> a constant from that point forward.
No,
On Thu, 14 Jul 2005, Lee Revell wrote:
>
> I don't think this will fly because we take a big performance hit by
> calculating HZ at runtime.
I think it might be an acceptable solution for a distribution that really
needed it, since it should be fairly simple. However, it's definitely not
the
On 7/15/05, Lee Revell <[EMAIL PROTECTED]> wrote:
> On Fri, 2005-07-15 at 02:04 +0200, Jesper Juhl wrote:
> > While reading this thread it occoured to me that perhaps what we
> > really want (besides sub HZ timers) might be for the kernel to
> > auto-tune HZ?
> >
> > Would it make sense to introduc
On Fri, 2005-07-15 at 02:04 +0200, Jesper Juhl wrote:
> While reading this thread it occoured to me that perhaps what we
> really want (besides sub HZ timers) might be for the kernel to
> auto-tune HZ?
>
> Would it make sense to introduce a new config option (say
> CONFIG_HZ_AUTO) that when select
On 7/13/05, Chris Wedgwood <[EMAIL PROTECTED]> wrote:
> On Wed, Jul 13, 2005 at 01:48:57PM -0700, Andrew Morton wrote:
>
> > Len Brown, a year ago: "The bottom line number to laptop users is
> > battery lifetime. Just today somebody complained to me that Windows
> > gets twice the battery life th
On Thu, 2005-07-14 at 16:49 -0700, Linus Torvalds wrote:
>
> On Thu, 14 Jul 2005, Lee Revell wrote:
> >
> > And I'm incredibly frustrated by this insistence on hard data when it's
> > completely obvious to anyone who knows the first thing about MIDI that
> > HZ=250 will fail in situations where H
On Thu, 2005-07-14 at 16:49 -0700, Linus Torvalds wrote:
> YOUR argument is "nobody else matters, only I do".
>
> MY argument is that this is a case of give and take.
I wouldn't say that. I do agree with you that HZ=1000 for everyone is
problematic, I just feel that a reasonable compromise is C
On Thu, 14 Jul 2005, Lee Revell wrote:
>
> And I'm incredibly frustrated by this insistence on hard data when it's
> completely obvious to anyone who knows the first thing about MIDI that
> HZ=250 will fail in situations where HZ=1000 succeeds.
Ok, guys. How many people have this MIDI thing? Ho
On Thu, 2005-07-14 at 16:25 -0700, Linus Torvalds wrote:
> On Thu, 14 Jul 2005, Lee Revell wrote:
> > This thread has really gone OT, but to revisit the original issue for a
> > bit, are you still unwilling to consider leaving the default HZ at 1000
> > for 2.6.13?
>
> Yes. I see absolutely no poi
On Thu, 2005-07-14 at 16:25 -0700, Linus Torvalds wrote:
> Yes. I see absolutely no point to it until I actually hear people who have
> actually tried some real load that doesn't work. Dammit, I want a real
> user who says that he can noticeable see his DVD stuttering, not some
> theory.
>
> I'
On Thu, 14 Jul 2005, Linus Torvalds wrote:
>
> But what you can do is to have HZ at some reasonably high value (ie in the
> kHz range), and then slow down the system clock to conserve energy, and
> increment jiffies by 16 or 32 when in "slow clock mode".
Btw, it doesn't have to even be a slow
On Thu, 14 Jul 2005, Lee Revell wrote:
>
> On Thu, 2005-07-14 at 09:37 -0700, Linus Torvalds wrote:
> > I have to say, this whole thread has been pretty damn worthless in
> > general in my not-so-humble opinion.
> >
>
> This thread has really gone OT, but to revisit the original issue for a
> b
On Thu, 14 Jul 2005, Alan Cox wrote:
>
> I suspect the problem for some of this is that people think of jiffies
> as incrementing by 1. If HZ is right then jiffies can be in nS, it just
> won't increment by 1.
No, jiffies _cannot_ be in nS, because of the fact that then it doesn't
fit in a wor
On Thu, 2005-07-14 at 09:37 -0700, Linus Torvalds wrote:
> I have to say, this whole thread has been pretty damn worthless in
> general in my not-so-humble opinion.
>
This thread has really gone OT, but to revisit the original issue for a
bit, are you still unwilling to consider leaving the defau
On Thu, 14 Jul 2005, Alan Cox wrote:
>
> > just doesn't realize that the latter is a bit more complicated exactly
> > because the latter is a hell of a lot more POWERFUL. Trying to get rid of
> > jiffies for some religious reason is _stupid_.
>
> Getting rid of jiffies in its current form is a
On Thu, Jul 14, 2005 at 01:41:44PM -0700, Christoph Lameter wrote:
> AFAIK John simply wants to change jiffies to count in nanoseconds
> since bootup and then call it "clock_monotonic".
Clocks and counter drift so calling it seconds would be
misleading. It would really only be good for approxima
On Iau, 2005-07-14 at 21:13, Linus Torvalds wrote:
> There is no way to avoid having some kind of counter to specify time.
> NONE. The only choice is what you base your notion of time on, and how you
> represent it. Do you represent it as two separate counters and try to make
> it look like "frac
> just doesn't realize that the latter is a bit more complicated exactly
> because the latter is a hell of a lot more POWERFUL. Trying to get rid of
> jiffies for some religious reason is _stupid_.
Getting rid of jiffies in its current form is a huge win for very
non-religious reasons. Jiffies i
On Thu, 2005-07-14 at 13:13 -0700, Linus Torvalds wrote:
>
> On Thu, 14 Jul 2005, john stultz wrote:
> >
> > We'll I'd probably put it as: "they do care about absolute time, but
> > they do not care about ticks or timer interrupt frequency"
>
> Well, the thing is, you have to count time some san
>Of course using APIC internal timers is generally the best idea on SMP,
>but they may have had reasons to avoid them (it's not an ISA interrupt,
so
>it could have been simply out of question in the initial design).
Best? No.
Local APIC timers are based on a clock which on many processors will
S
Vojtech Pavlik <[EMAIL PROTECTED]> writes:
> HPETs have a fixed frequency (usually 14.31818 MHz, but that depends
> on the manufacturer).
>
>> - 64-bit "match timer" (i.e., a register in the counter which fires IRQ
>> when it matches the counter value)
>
> That's implemented in the HPET hardware
On Thu, 14 Jul 2005, Linus Torvalds wrote:
> So the _sane_ way to do timeouts is to define an _arbitrary_ clock that is
> just an integer counter. None of this "nanoseconds + full seconds" crap.
> None of this stupid confusion with "real time". You select something that
> is conceptually _clear
On Thu, Jul 14, 2005 Linus Torvalds wrote:
> In other words, the _right_ way to do this is literally
>
> unsigned long timeout = jiffies + HZ/2;
> for (;;) {
> if (ready())
> return 0;
> if (time_after(timeout, jiffies))
>
On Thu, Jul 14, 2005 at 01:06:00PM -0700, Linus Torvalds wrote:
> On Thu, 14 Jul 2005, Russell King wrote:
> > Umm. Except, according to your description of what it's supposed to
> > do, the above code can have an accumulating error.
>
> No. It can have a local drift, but the point is, the error
On Thu, 14 Jul 2005, john stultz wrote:
>
> We'll I'd probably put it as: "they do care about absolute time, but
> they do not care about ticks or timer interrupt frequency"
Well, the thing is, you have to count time some sane way.
You can do it by having very expensive data structures that sa
On Thu, 14 Jul 2005, Russell King wrote:
>
> Umm. Except, according to your description of what it's supposed to
> do, the above code can have an accumulating error.
No. It can have a local drift, but the point is, the error never gets
worse - it _stays_ local.
There's no point in polling tw
On Thu, 2005-07-14 at 19:02 +0200, Arjan van de Ven wrote:
> On Thu, 2005-07-14 at 09:37 -0700, Linus Torvalds wrote:
> > just doesn't realize that the latter is a bit more complicated exactly
> > because the latter is a hell of a lot more POWERFUL. Trying to get rid of
> > jiffies for some relig
On Thu, 2005-07-14 at 09:37 -0700, Linus Torvalds wrote:
>
> On Thu, 14 Jul 2005, Vojtech Pavlik wrote:
> >
> > A note on the relaive timer API: There needs to be a way to say
> > "x milliseconds from the time this timer should have triggered" instead
> > of "x milliseconds from now", to avoid s
On Thu, Jul 14, 2005 at 10:21:41AM -0700, Linus Torvalds wrote:
> In other words, the _right_ way to do this is literally
>
> unsigned long timeout = jiffies + HZ/2;
> for (;;) {
> if (ready())
> return 0;
> if (time_after(timeout, jiff
On Thu, 14 Jul 2005, Jan Engelhardt wrote:
>
> >> >>> What does Windows do here?
> >> >> windows xp base rate is 100Hz... but multimedia apps can ask for almost
> >> > 83Hz
> >> Well, Windoes 98 (vmmon) shows very different ones:
> >Wow. Windows has been doing this since *98*?
>
> ...since Win
>> >>> What does Windows do here?
>> >> windows xp base rate is 100Hz... but multimedia apps can ask for almost
>> > 83Hz
>> Well, Windoes 98 (vmmon) shows very different ones:
>Wow. Windows has been doing this since *98*?
...since Windows does multitask scheduling I suppose, which is since 95 o
Vojtech Pavlik <[EMAIL PROTECTED]> wrote:
>
> A note on the relaive timer API: There needs to be a way to say
> "x milliseconds from the time this timer should have triggered" instead
> of "x milliseconds from now", to avoid skew in timers that try to be
> strictly periodic.
mod_timer(t
On Thu, 2005-07-14 at 09:37 -0700, Linus Torvalds wrote:
>
> There's absolutely nothing wrong with "jiffies", and anybody who
> thinks that
>
> msleep(20);
>
> is fundamentally better than
>
> timeout = jiffies + HZ/50;
>
What's wrong with structured programming?
-
To unsubscribe f
On Thu, 14 Jul 2005, Chris Friesen wrote:
>
> But if all I really want is to sleep for 20ms, what does the additional
> power actually buy me?
If you _only_ want to sleep for 20ms, it doesn't buy you anything.
But the sleep is often part of a bigger picture, where the 20ms might be
part of a
On Thu, 14 Jul 2005, Arjan van de Ven wrote:
>
> I *will* argue that for relative delays in drivers, msleep() is better.
Oh, I agree.
I think we should continue the simplification of the simple stuff. If
somebody just wants to sleep a while, do it.
But if somebody is doing this because they
Linus Torvalds wrote:
There's absolutely nothing wrong with "jiffies", and anybody who thinks
that
msleep(20);
is fundamentally better than
timeout = jiffies + HZ/50;
just doesn't realize that the latter is a bit more complicated exactly
because the latter is a hell of a lo
On Thu, 2005-07-14 at 09:37 -0700, Linus Torvalds wrote:
> There should be an _absolute_ interface
I'm not arguing there shouldn't be an absolute interface. I'm arguing
that *most* uses are relative, and as such a relative interface makes
sense for those cases.
> Btw, this is exactly why the j
On Thu, 14 Jul 2005, Vojtech Pavlik wrote:
>
> A note on the relaive timer API: There needs to be a way to say
> "x milliseconds from the time this timer should have triggered" instead
> of "x milliseconds from now", to avoid skew in timers that try to be
> strictly periodic.
I disagree.
Ther
On Thu, 2005-07-14 at 08:02 -0700, Christoph Lameter wrote:
> I doubt that increasing the timer frequency is the way to go to solve
> these issues. HZ should be as low as possible and we should strive for
> a tickless system.
Agreed. Most of those applications are driven by their own interrupt
s
On Thu, 14 Jul 2005, Lee Revell wrote:
> On Thu, 2005-07-14 at 10:38 +0200, Ingo Molnar wrote:
> > - there are real-time applications (robotic environments: fast rotating
> >tools, media and mobile/phone applications, etc.) that want 10
> >usecs precision. If such users increased HZ to 10
On Thu, 2005-07-14 at 10:38 +0200, Ingo Molnar wrote:
> - there are real-time applications (robotic environments: fast rotating
>tools, media and mobile/phone applications, etc.) that want 10
>usecs precision. If such users increased HZ to 100,000 or even
>1000,000, the current timer i
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On Wed, 13 Jul 2005, Jan Engelhardt wrote:
> >
> > No, some kernel code causes a triple-fault-and-reboot when the HZ is >=
> > 10KHz. Maybe the highest possible value is 8192 Hz, not sure.
>
> Can you post the triple-fault message? It really shouldn't
On Thu, 2005-07-14 at 11:24 +0200, Jan Engelhardt wrote:
> "My expectation is if we want to beat the competition, we'll want
> the ability to go *under* 100Hz."
> >>>
> >>> What does Windows do here?
> >>
> >> windows xp base rate is 100Hz... but multimedia apps can ask for almost
> >
>
On Thu, Jul 14, 2005 at 12:25:40PM +0200, Krzysztof Halasa wrote:
> Linus Torvalds <[EMAIL PROTECTED]> writes:
>
> > And in short-term things, the timeval/jiffie conversion is likely to be a
> > _bigger_ issue than the crystal frequency conversion.
> >
> > So we should aim for a HZ value that mak
On Thu, Jul 14, 2005 at 09:42:18AM +0200, Arjan van de Ven wrote:
> > IOW, nothing ever sees any "variable frequency", and there's never any
> > question about what the timer tick is: the timer tick is 2kHz as far as
> > everybody is concerned. It's just that the ticks sometimes come in
> > "bu
Linus Torvalds <[EMAIL PROTECTED]> writes:
> And in short-term things, the timeval/jiffie conversion is likely to be a
> _bigger_ issue than the crystal frequency conversion.
>
> So we should aim for a HZ value that makes it easy to convert to and from
> the standard user-space interface formats.
On Wed, 13 Jul 2005, Benjamin LaHaise wrote:
> That's one thing I truely dislike about the current timer code. If we
> could program the RTC interrupt to come into the system as an NMI (iirc
> oprofile already has code to do this), we could get much better TSC
> interpolation since we would be
On Wed, 13 Jul 2005, Lee Revell wrote:
> Did anyone else find this strange:
>
> "The RTC is used in periodic mode to provide the system profiling
> interrupt on uni-processor systems and the clock interrupt on
> multi-processor systems."
>
> We just take NR_CPUS * HZ timer interrupts per second,
"My expectation is if we want to beat the competition, we'll want
the ability to go *under* 100Hz."
>>>
>>> What does Windows do here?
>>
>> windows xp base rate is 100Hz... but multimedia apps can ask for almost
>
> 83Hz
Well, Windoes 98 (vmmon) shows very different ones:
/dev/vmmon[
1 - 100 of 205 matches
Mail list logo
