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
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
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) {
+
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) {
+
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
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
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 straightforward.
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 is unset, );
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 = %s, , str);
+
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
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
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 mode
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 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 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 Hz, not sure.
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.
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)
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(_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
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
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
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 Grover over
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 overall has
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 times normal
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/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) to
250 causes my
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. So
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
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
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
> 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
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
>
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
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
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
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
>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
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
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
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
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
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
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
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
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.
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
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
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 being
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 agree.
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't
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
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 timers are
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
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
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 - thats
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
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 actually make the
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 clock
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 a
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 work
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 the first
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 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 latencies are only
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. So if you are
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
significance.
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 will
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
wants to
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 mix
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 that
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
the
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 other
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 simple and
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 with
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
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
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
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
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.
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
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
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.expires = jiffies + n
> add_timeout();
> while(!timeout_expired())
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
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.
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
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
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
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
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
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?
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
1 - 100 of 405 matches
Mail list logo
