On Mon, 2007-07-30 at 11:27 +0200, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > @@ -508,7 +508,9 @@ inline fastcall void raise_softirq_irqof
> > {
> > __do_raise_softirq_irqoff(nr);
> >
> > +#ifdef CONFIG_PREEMPT_SOFTIRQ
On Sun, 2007-07-29 at 22:20 -0700, Arjan van de Ven wrote:
> >
> > +/*
> > + * trigger a reschedule on all other CPUs:
> > + */
> > +extern void smp_send_reschedule_allbutself(void);
> > +
> > +/*
> > + * trigger a reschedule on all other CPUs:
> > + */
> > +extern void smp_send_reschedule_allbut
On Mon, 2007-07-30 at 11:39 +0200, Peter Zijlstra wrote:
> On Sun, 2007-07-29 at 19:45 -0700, Daniel Walker wrote:
>
> > +#undef TYPE_EQUAL
> > +#define TYPE_EQUAL(var, type) \
> > + __builtin_types_compatible_p(typeof(var), type *)
> > +
>
> If yo
On Mon, 2007-07-23 at 21:55 +0200, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > These two WARN_ON calls send my system into a boot hang. They trigger
> > over and over , some examples below.
>
> hm, could you try to figure out why they
> 2 files changed, 149 insertions(+), 51 deletions(-)
Here's a simpler version .. uses the plist data structure instead of the
100 queues, which makes for a cleaner patch ..
Signed-off-by: Daniel Walker <[EMAIL PROTECTED]>
---
include/linux/workqueue.h
On Wed, 2007-08-01 at 07:59 -0400, Gregory Haskins wrote:
> On Tue, 2007-07-31 at 20:52 -0700, Daniel Walker wrote:
>
> >
> > Here's a simpler version .. uses the plist data structure instead of the
> > 100 queues, which makes for a cleaner patch ..
>
> Hi D
On Wed, 2007-08-01 at 11:19 -0400, Gregory Haskins wrote:
> On Wed, 2007-08-01 at 08:10 -0700, Daniel Walker wrote:
>
> >
> > rt_mutex_setprio() is just a function. It was also designed specifically
> > for PI , so it seems fairly sane to use it in other PI type
> &g
On Wed, 2007-08-01 at 19:01 +0200, Peter Zijlstra wrote:
> (you guys forgot to CC Ingo, Oleg and me)
>
> On Tue, 2007-07-31 at 20:52 -0700, Daniel Walker wrote:
>
> > Here's a simpler version .. uses the plist data structure instead of the
> > 100 queues, wh
On Wed, 2007-08-01 at 22:12 +0400, Oleg Nesterov wrote:
> And I personally think it is not very useful, even if it was correct.
> You can create your own workqueue and change the priority of cwq->thread.
This change is more dynamic than than just setting a single priority ..
There was some other
On Wed, 2007-08-01 at 22:26 +0400, Oleg Nesterov wrote:
> No, the "tail" option has nothing to do with prioritize, we can't remove
> it. Please look at the code.
So you insert a work struct that executes last which wakes the flushing
thread?
> Also, flush_workqueue() must not be delayed by the n
On Thu, 2007-08-02 at 00:18 +0400, Oleg Nesterov wrote:
> On 08/01, Daniel Walker wrote:
> >
> > On Wed, 2007-08-01 at 22:12 +0400, Oleg Nesterov wrote:
> >
> > > And I personally think it is not very useful, even if it was correct.
> > > You can create you
On Thu, 2007-08-02 at 00:32 +0400, Oleg Nesterov wrote:
> On 08/02, Oleg Nesterov wrote:
> >
> > And I don't understand why rt_mutex_setprio() is called just before
> > calling work->func(). This means that a high-priority work could
> > be delayed by the low-priority ->current_work.
>
> Aha, I mi
On Thu, 2007-08-02 at 00:50 +0400, Oleg Nesterov wrote:
> On 08/01, Daniel Walker wrote:
> >
> > On Thu, 2007-08-02 at 00:18 +0400, Oleg Nesterov wrote:
> > > On 08/01, Daniel Walker wrote:
> > > >
> > > > On Wed, 2007-08-01 at 22:12 +0400, Oleg Nes
On Tue, 2007-10-16 at 10:50 -0400, Dave Johnson wrote:
>
> range of tsc_khz # of boots % of boots
> - -- --
> < 1999750 0 0.000%
> 1999750 - 1999800 21 3.048%
> 1999800 - 1999850 166 24.128%
> 1999850 - 100
On Mon, 2007-10-22 at 14:15 +0200, Peter Zijlstra wrote:
> Daniel wrote this bit, but I tend to agree with him, but can't give his
> rationale. Mine is that worklets are typically asynchonous and thus its
> prio should not depend on temporal things like boosting.
>
> OTOH it would probably make s
nup to do in that regard.
Signed-off-by: Daniel Walker <[EMAIL PROTECTED]>
---
include/linux/seqlock.h | 26 +++---
1 file changed, 15 insertions(+), 11 deletions(-)
Index: linux-2.6.23/include/linux/seqlock.h
===
On Thu, 2007-10-11 at 10:49 -0400, Steven Rostedt wrote:
> > ---
> > include/linux/spinlock.h |2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > Index: linux-2.6.23-rc9-rt2/include/linux/spinlock.h
> > ===
> > --- l
On Mon, 2007-10-15 at 14:14 -0400, Steven Rostedt wrote:
> > This is the second fix for this .. The first was in this email (over a
> > month ago)
> >
> > http://lkml.org/lkml/2007/8/31/318
>
> You're right I missed that. (I even read it). But for fixes like this, (or
> any patches that are not i
On Mon, 2007-10-15 at 23:35 +0200, Thomas Gleixner wrote:
> On Mon, 15 Oct 2007, Daniel Walker wrote:
> > On Mon, 2007-10-15 at 14:14 -0400, Steven Rostedt wrote:
> >
> > > > This is the second fix for this .. The first was in this email (over a
> > > > mon
you boot test this patch?
---
Move the read_seqbegin() call up in the chain so the value
can be returned
Signed-off-by: Daniel Walker <[EMAIL PROTECTED]>
---
include/linux/seqlock.h |7 +++
1 file changed, 3 insert
On Wed, 2007-10-17 at 11:10 -0400, Steven Rostedt wrote:
> > >
> > > #define read_seqbegin_irqsave(lock, flags) \
> > > -do { \
> > > +({ \
> > > fla
test case which would
soft hang occasionally.
The patch reworks do_futex, and futex_wait* so a NULL pointer in the timeout
position is infinite, and anything else is evaluated as a real timeout.
Signed-Off-By: Daniel Walker <[EMAIL PROTECTED]>
---
kernel/futex.c| 14 ++
On Thu, 2007-01-18 at 13:26 +0100, Pierre Peiffer wrote:
> Ingo Molnar a écrit :
> > * Daniel Walker <[EMAIL PROTECTED]> wrote:
> >
> [...]
> >> The patch reworks do_futex, and futex_wait* so a NULL pointer in the
> >> timeout position is infinite
This patchset represents the most stable clocksource changes in my tree. Also
John (and others) have reviewed these changes a few times. I think it's all
acceptable.
Daniel
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [
Move the generic timekeeping code from kernel/timer.c to
kernel/time/timekeeping.c . This requires some glue code which is
added to the include/linux/timekeeping.h header.
Signed-Off-By: Daniel Walker <[EMAIL PROTECTED]>
---
include/linux/clocksource.h |3
include/linux/timekee
Adds a call back interface for register/rating change events. This is also used
later in this series to signal other interesting events.
Signed-Off-By: Daniel Walker <[EMAIL PROTECTED]>
---
include/linux/clocksource.h | 37 +
include/linux/timekee
Update drivers/clocksource/ with list initialization.
Signed-Off-By: Daniel Walker <[EMAIL PROTECTED]>
---
drivers/clocksource/acpi_pm.c|1 +
drivers/clocksource/cyclone.c|1 +
drivers/clocksource/scx200_hrt.c |1 +
3 files changed, 3 insertions(+)
Index: linux-
A change to clocksource initialization. If the list field is initialized
it allows clocksource_register to complete faster since it doesn't have
to scan the list of clocks doing strcmp on each looking for duplicates.
Signed-Off-By: Daniel Walker <[EMAIL PROTECTED]>
---
Update arch/x86_64/ with list initialization.
Signed-Off-By: Daniel Walker <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/hpet.c |1 +
arch/x86_64/kernel/tsc.c |1 +
2 files changed, 2 insertions(+)
Index: linux-2.6.19/arch/x86_64/kernel/
Update arch/i386/ with list initialization.
Signed-Off-By: Daniel Walker <[EMAIL PROTECTED]>
---
arch/i386/kernel/hpet.c |1 +
arch/i386/kernel/i8253.c |1 +
arch/i386/kernel/tsc.c |1 +
3 files changed, 3 insertions(+)
Index: linux-2.6.19/arch/i386/kernel/
Update arch/mips/ with list initialization.
Signed-Off-By: Daniel Walker <[EMAIL PROTECTED]>
---
arch/mips/kernel/time.c |1 +
1 file changed, 1 insertion(+)
Index: linux-2.6.19/arch/mips/kernel/time.c
===
--- linux-
Update arch/avre32/ with list initialization.
Signed-Off-By: Daniel Walker <[EMAIL PROTECTED]>
---
arch/avr32/kernel/time.c |1 +
1 file changed, 1 insertion(+)
Index: linux-2.6.19/arch/avr32/kernel/time.c
===
--- linux-
Update arch/arm/ with list initialization.
Signed-Off-By: Daniel Walker <[EMAIL PROTECTED]>
---
arch/arm/mach-imx/time.c |1 +
arch/arm/mach-ixp4xx/common.c |1 +
arch/arm/mach-netx/time.c |1 +
arch/arm/mach-pxa/time.c |1 +
4 files changed, 4 insertions(+)
a more
interesting order. It's forward looking.
Signed-Off-By: Daniel Walker <[EMAIL PROTECTED]>
---
arch/i386/kernel/tsc.c |2
arch/x86_64/kernel/tsc.c|2
include/linux/clocksource.h |9 ++-
kernel/time/clocksource.c | 132 +---
x27;s needed.
The fast path is also reduced to checking a single atomic value.
Signed-Off-By: Daniel Walker <[EMAIL PROTECTED]>
---
include/linux/clocksource.h |5
include/linux/timekeeping.h | 10
kernel/time/clocksource.c |6 +
kernel/time/timekeeping
Uses the block notifier to replace the functionality of update_callback().
update_callback() was a special case specifically for the tsc, but including
it in the clocksource structure duplicated it needlessly for other clocks.
Signed-Off-By: Daniel Walker <[EMAIL PROTECTED]>
---
arc
On Tue, 2007-01-23 at 13:42 +0100, Haavard Skinnemoen wrote:
> On 1/23/07, Daniel Walker <[EMAIL PROTECTED]> wrote:
> > Update arch/avre32/ with list initialization.
> >
> > Signed-Off-By: Daniel Walker <[EMAIL PROTECTED]>
>
> Looks good to me, although I su
On Tue, 2007-01-23 at 22:00 +, Thomas Gleixner wrote:
> - Provide a generic way to verify clocksources. TSC needs
>verification due to broken hardware and BIOS implementations. The
>previous attempt to allow TSC usage for high resolution and/or
>dynamic ticks only in combination wi
On Tue, 2007-01-23 at 18:23 -0800, Andrew Morton wrote:
> > There appears to be some fairly clear duplication between my clocksource
> > tree and this release of high resolution timers. Not to mention that we
> > both submitted our tree's to Andrew within days .
> >
> > To lessen Andrews burden
On Wed, 2007-01-24 at 08:07 +0100, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > To lessen Andrews burden it would be wise to integrate the two trees
> > prior to anything going into -mm .. [...]
>
> i disagree. Thomas' tree has been
On Wed, 2007-01-24 at 10:51 +0100, Ingo Molnar wrote:
> please read what i wrote: in the first section above i am talking about
> Thomas' -hrt tree and its track record. Thomas' tree is more than a year
> old and has an excellent track record. In the last sentence i was
> talking about this lat
On Wed, 2007-01-24 at 11:29 +0100, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > No, the test config I was talking about is SMP i386 (which is what I
> > usually use). [...]
>
> then please send me the .config.
Sure.
Daniel
#
# Autom
On Wed, 2007-01-24 at 12:13 +0100, Thomas Gleixner wrote:
> On Wed, 2007-01-24 at 02:23 -0800, Daniel Walker wrote:
> > > the 10th major iteration to his codebase. If you have cleanups to his
> > > code then please work with Thomas to get your changes into his tree.
&g
r and hpet (or pit or whatever) . Clearly the
implementation details could be worked on but the clock access would
remain largely the same.
Signed-Off-By: Daniel Walker <[EMAIL PROTECTED]>
---
arch/i386/kernel/tsc.c | 93
include/linux/clock
On Wed, 2007-01-24 at 20:38 +0100, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > > you are also misunderstanding the change. While the TSC is the only
> > > unstable clocksource right now, the previous code tied the TSC to
> > >
On Wed, 2007-01-24 at 11:57 -0800, john stultz wrote:
> On Wed, 2007-01-24 at 01:30 -0800, Daniel Walker wrote:
> >
> > My patch set has been stable for months, and reviewed and tested by
> > John and I constantly (With you and Thomas on the CC list each
> > release)..
On Wed, 2007-01-24 at 13:23 -0800, john stultz wrote:
> Well, I suggested the kernel/time/timekeeping.c change go in last cycle,
> when you pushed your other cleanups, because that sort of large,
> move-tons-of-code patch sucks to keep out of the tree for long as it
> would surely collide with som
On Thu, 2007-01-25 at 07:32 +0100, Ingo Molnar wrote:
> * john stultz <[EMAIL PROTECTED]> wrote:
>
> > Although, to be fair, I do know that Daniel has future sched_clock
> > related patches that need his cleanups [...]
>
> btw., i dont find those sched_clock() changes really acceptable in their
On Fri, 2006-12-22 at 13:39 -0800, Chen, Tim C wrote:
> Wonder if you have any suggestions on what could cause the slowdown.
> We've tried disabling CONFIG_NO_HZ and it didn't help much.
Did you compare PREEMPT_RT with vanilla PREEMPT ? Or one version of
PREEMPT_RT vs. another ?
Daniel
-
To u
On Fri, 2006-12-22 at 02:43 -0800, Stephane Eranian wrote:
> Hello,
>
>
> The perfmon subsystems needs to compute per-CPU duration. It is using
> sched_clock() to provide this information. However, it seems they are
> big variations in the way sched_clock() is implemented for each architectures,
: Daniel Walker <[EMAIL PROTECTED]>
---
include/linux/hrtimer.h |2 +-
kernel/hrtimer.c|2 --
kernel/time/ntp.c |2 ++
kernel/timer.c |1 +
4 files changed, 4 insertions(+), 3 deletions(-)
Index: linux-2.6.19/include/linux/hrt
On Wed, 2006-12-27 at 18:39 +0100, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > These calls were getting inconsistent wrt. the xtime_lock. The
> > xtime_lock should be held when doing the warp check update, and
> > interrupts should be o
On Wed, 2006-12-27 at 09:53 -0800, Daniel Walker wrote:
> The system hang was resolved by changing the irq threads to all prio
> 50 ..
Guess I was wrong about this.. The hang was resolved, but I's not sure
how yet ..
Daniel
-
To unsubscribe from this list: send the line "u
On Wed, 2006-12-27 at 10:04 -0800, Daniel Walker wrote:
> On Wed, 2006-12-27 at 09:53 -0800, Daniel Walker wrote:
>
> > The system hang was resolved by changing the irq threads to all prio
> > 50 ..
>
> Guess I was wrong about this.. The hang was resolved, but I's
I got some scheduling while atomic on x86-64 , and since x86-64 doesn't seem
to have HIGHMEM there's no workaround for kmap_atomic() .
This patch adds the same as i386 HIGHMEM for !HIGHMEM.
Signed-Off-By: Daniel Walker <[EMAIL PROTECTED]>
---
include/linux/highmem.h | 14 +
On Wed, 2006-12-27 at 21:54 +0100, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > I got some scheduling while atomic on x86-64 , [...]
>
> please post those messages too.
>
> Ingo
Ok .. This is from 2.6.20-rc2-rt0 tho .
BUG: sc
On Wed, 2006-12-27 at 22:25 +0100, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > I got some scheduling while atomic on x86-64 , and since x86-64
> > doesn't seem to have HIGHMEM there's no workaround for kmap_atomic() .
> >
>
On Wed, 2006-12-27 at 22:31 +0100, Ingo Molnar wrote:
> plus on i386 the fix below is needed as well.
>
We do it on most other arches .. PowerPC , and I think ARM too.
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
On Wed, 2006-12-27 at 22:25 +0100, Ingo Molnar wrote:
>
> +void pagefault_disable(void)
> +{
> + current->pagefault_disabled++;
> + /*
> +* make sure to have issued the store before a pagefault
> +* can hit.
> +*/
> + barrier();
> +}
> +
> +void pagefault_
On Wed, 2006-12-27 at 22:25 +0100, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > I got some scheduling while atomic on x86-64 , and since x86-64
> > doesn't seem to have HIGHMEM there's no workaround for kmap_atomic() .
> >
>
Got several of the messages below on 2.6.20-rc2-mm1 .
Dec 29 03:34:08 10 kernel: [ 264.519401] BUG: at arch/i386/mm/highmem.c:50
kmap_atomic()
Dec 29 03:34:08 10 kernel: [ 264.524973] []
show_trace_log_lvl+0x1a/0x2f
Dec 29 03:34:08 10 kernel: [ 264.530129] [] show_trace+0x12/0x14
Dec 29
Got this while trying to mount a ext3 block device. The host was running nfs
root
[ 929.130331] nfs: server 10.0.13.21 not responding, still trying
[ 931.346289] BUG: soft lockup detected on CPU#3!
[ 931.350860] [] show_trace_log_lvl+0x1a/0x2f
[ 931.356081] [] show_trace+0x12/0x14
[ 931.
:
. [] __spin_lock+0x16/0x80
[] .. ( <= remove_proc_entry+0x4b/0x230)
Signed-Off-By: Daniel Walker <[EMAIL PROTECTED]>
---
fs/proc/generic.c |3 ++-
1 files changed, 2 insertions(+), 1 deletion(-)
Index: linux-2.6.19/fs/proc/
nside rtmutex.c I
suspect it would be a benefit to move that all into a header and ifdef
only in the header .
Daniel
Signed-Off-By: Daniel Walker <[EMAIL PROTECTED]>
---
include/linux/lock_stat.h | 25 +++--
kernel/lock_stat.c| 34 ++
les
static.
Signed-Off-By: Daniel Walker <[EMAIL PROTECTED]>
---
drivers/media/video/bt8xx/bttv-input.c |4 ++--
drivers/media/video/saa7134/saa7134-input.c |4 ++--
include/media/ir-common.h |3 ---
3 files changed, 4 insertions(+), 7 deletions(-)
Ind
hooks.c" 5014 lines --95%--
4811,35 96%
This could be a bug report cause I bet there's a better way to make these
mutually
exclusive.
Signed-Off-By: Daniel Walker <[EMAIL PROTECTED]>
---
security/slim/Kconfig |2 +-
1 f
Sorry, really for -mm .
On Sat, 2006-12-30 at 07:48 -0800, Daniel Walker wrote:
> If you have both SLIM and selinux compiled into your kernel selinux will panic
> if it can't register itself. The code below,
>
> if (register_security (&selinux_ops))
> panic(&quo
.
Interesting to note that you could crash your system here if you just load the
modules in the wrong order.
Signed-Off-By: Daniel Walker <[EMAIL PROTECTED]>
---
net/atm/common.c |3 ++-
1 files changed, 2 insertions(+), 1 deletion(-)
Index: linux-2.6.19/net/atm/co
110 rip 8118c110 rsp
> 7fff9a9d14d8 error 15
>
Does this seem like an appropriate solution? This just reconstitutes
Ingo's patch by removing the unlikely calls that got added recently.
Maybe a comment into vsyscall.c that says to stay away from all macro's
and possible
On Sun, 2006-12-31 at 12:43 -0800, Randy Dunlap wrote:
> On Sun, 31 Dec 2006 11:45:09 -0800 Daniel Walker wrote:
>
> > On Sun, 2006-12-31 at 23:04 +0800, Fengguang Wu wrote:
> > > Hi,
> > >
> > > The following messages keeps popping up when CONFIG_PROFILE_L
On Tue, 2007-01-02 at 13:05 -0500, Mimi Zohar wrote:
> Being able to compile both SELinux and SLIM into the kernel was done
> intentionally. The kernel parameters 'selinux' and 'slim' can enable
> or disable the LSM module at boot. Perhaps, for the time being, the
> SECURITY_SLIM_BOOTPARAM_VALUE
On Tue, 2007-02-20 at 20:53 -0800, Linus Torvalds wrote:
> Ok, the merge window for 2.6.21 has closed, and -rc1 is out there.
>
> There's a lot of changes, as is usual for an -rc1 thing, but at least so
> far it would seem that 2.6.20 has been a good base, and I don't think we
> have anything *r
On Wed, 2007-02-21 at 18:07 +0100, Thomas Gleixner wrote:
> On Wed, 2007-02-21 at 08:24 -0800, Daniel Walker wrote:
> > > The most interesting core change may be the dyntick/nohz one, where timer
> > > ticks will only happen when needed. It's been brewing for a _loong
On Wed, 2007-02-21 at 18:41 +0100, Thomas Gleixner wrote:
> On Wed, 2007-02-21 at 09:19 -0800, Daniel Walker wrote:
> > > At this point the PIT / HPET _is_ active and incrementing jiffies. The
> > > switch to local apic timers happens afterwards.
> >
> > Co
On Wed, 2007-02-21 at 19:18 +0100, Thomas Gleixner wrote:
> On Wed, 2007-02-21 at 09:38 -0800, Daniel Walker wrote:
> > > >
> > > > Could be the switch over then which confuses the NMI .
> > >
> > > Why? The switch just stops the PIT/HPET. It does
On Wed, 2007-02-21 at 20:23 +0100, Thomas Gleixner wrote:
> On Wed, 2007-02-21 at 10:23 -0800, Daniel Walker wrote:
> > Right, but eventually there isn't a regular timer interrupt through the
> > io-apic. I don't think in the past IRQ0 stops without the system
> > c
On Wed, 2007-02-21 at 20:23 +0100, Thomas Gleixner wrote:
> On Wed, 2007-02-21 at 10:23 -0800, Daniel Walker wrote:
> > Right, but eventually there isn't a regular timer interrupt through the
> > io-apic. I don't think in the past IRQ0 stops without the system
> > c
On Wed, 2007-02-21 at 21:43 +0100, Thomas Gleixner wrote:
> On Wed, 2007-02-21 at 12:00 -0800, Daniel Walker wrote:
> > There's a compile failure during my bisect.
> >
> > distcc[3863] ERROR: compile /tmp//hrtimer.tmp.dwalker1.3795.i on
> > dwalker3/120 failed
&
On Wed, 2007-02-21 at 13:06 -0800, Linus Torvalds wrote:
>
> On Wed, 21 Feb 2007, Daniel Walker wrote:
> >
> > Here's the final commit from the bisect which caused it . It says "No
> > changes to existing functionality" ?
>
> Ok, it wouldn't
On Sat, 2007-02-24 at 11:19 -0500, Mathieu Desnoyers wrote:
> Hi,
>
> I am trying to improve the Linux kernel time source so it can be read
> without seqlock from NMI handlers. I have also seen some interest for
> such an accurate monotonic clock readable from user space. It mainly
> implies an at
On Mon, 2007-02-26 at 15:53 -0500, Mathieu Desnoyers wrote:
> > > /* On frequency change event */
> > > /* In irq context */
> > > void freq_change_cb(unsigned int new_freq)
> > > {
> >
> > It's possible for the TSC to change frequencies without notification. It
> > can also completely stop when
On Mon, 2007-02-26 at 17:14 -0500, Mathieu Desnoyers wrote:
> For kernel and user space tracing, those small jumps are very annoying :
> it can show, in a trace, that a fork() appears on a CPU after the first
> schedule() of the thread on the other CPU : scheduling causality relationship
> can be
On Mon, 2007-02-26 at 22:54 -0500, Mathieu Desnoyers wrote:
> If an NMI nests over the spinlock, we have a deadlock.
Maybe not completely safe ...
> In addition, clock->cycle_last is a cycle_t, defined as a 64 bits on
> x86. If is therefore not updated atomically by change_clocksource,
> timekeep
On Tue, 2007-02-27 at 07:29 +0100, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > The pit clocksource could be dropped pretty easy with my clocksource
> > update patches, which I'm still working on but you could easily drop
> > clock
On Tue, 2007-02-27 at 02:38 -0500, Mathieu Desnoyers wrote:
>
> I am concerned about the automatic fallback to the PIT when no other
> clock source is available. A clocksource read would be atomic when TSC
> or HPET are available, but would fall back on PIT otherwise. There
> should be some way t
On Tue, 2007-02-27 at 11:02 -0500, Mathieu Desnoyers wrote:
> * Daniel Walker ([EMAIL PROTECTED]) wrote:
> > On Tue, 2007-02-27 at 02:38 -0500, Mathieu Desnoyers wrote:
> >
> > >
> > > I am concerned about the automatic fallback to the PIT when no other
&
On Tue, 2007-02-27 at 14:04 -0500, Mathieu Desnoyers wrote:
> 1 - I do not plan to use the rcupdate.h API, because it is oriented
> towards allowing/freeing data structures after a quiescent state. I
> don't need that. I only want to have a 64 bits data structure valid for
> reading, with atomic u
I released another version of my clocksource update. I incorporated some
of Ingo's suggestions. I also tested my changes on an older Sony Vaio
where the TSC stops in C2/C3. I noticed that generic time already marks
the TSC unstable if the system enters C2/C3 . So the verify code doesn't
need to ru
The /proc/interrupts timer entry is dangling a little. With PREEMPT_RT
the entry doesn't get updated ..
My system after two hours uptime,
CPU0 CPU1
0: 56 0 IO-APIC-edge timer
1: 2 0 IO-APIC-edge i8042
4: 1450
It appears there a problem with the /proc/interrupts entry for
"timer" .. It doesn't increment anymore .. This problem exists in the
-rt tree also .. I haven't done a bisect , but I'm assuming this is HRT
related ..
Also my NMI watchdog isn't functioning , which also exists in the -rt
tree, and -
On Tue, 2007-02-06 at 19:36 +0100, Thomas Gleixner wrote:
> On Tue, 2007-02-06 at 08:03 -0800, Daniel Walker wrote:
> > It appears there a problem with the /proc/interrupts entry for
> > "timer" .. It doesn't increment anymore .. This problem exists in the
> &g
On Tue, 2007-02-06 at 20:07 +0100, Thomas Gleixner wrote:
> On Tue, 2007-02-06 at 10:45 -0800, Daniel Walker wrote:
> > > > -rt tree also .. I haven't done a bisect , but I'm assuming this is HRT
> > > > related ..
> > >
> > > And w
On Tue, 2007-02-06 at 21:20 +0100, Thomas Gleixner wrote:
> On Tue, 2007-02-06 at 11:55 -0800, Daniel Walker wrote:
> > > What kind of artificial problem are you creating here ?
> >
> > I'm not trying to create anything .. However, as I said before
> > the /pr
On Tue, 2007-02-06 at 21:52 +0100, Ingo Molnar wrote:
> Well, if you enable dynticks you should expect the number of timer irqs
> to go down. There's no problem here.
Ok .
> > The reason that I'm bringing it up at all is because people have ask
> > me "Why isn't my timer ticking??"
>
> it's q
On Tue, 2007-02-06 at 22:09 +0100, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > > it's quite easy to explain: because of the new dynticks feature.
> > > Both 'timer' and 'LOC' counts go way down.
> >
>
On Tue, 2007-02-06 at 22:17 +0100, Thomas Gleixner wrote:
> > The reason that I'm bringing it up at all is because people have ask me
> > "Why isn't my timer ticking??"
>
> So it's a problem of user perception and not of a user space regression.
> Please stop confusing things.
At least we agree
On Tue, 2007-02-06 at 22:41 +0100, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > > we could make this clearer by renaming 'LOC' (which stands for
> > > 'LOCal timer interupts' and was added [and misnamed] by yours truly
On Tue, 2007-02-06 at 22:43 +0100, Thomas Gleixner wrote:
> > I think the regression (if you can call it that) is not scripts
> > crashing, but more people not know what's going on with there system ..
>
> I did not hear a complaint of anyone except you. I doubt that there will
> be a big confus
On Tue, 2007-02-06 at 23:08 +0100, Ingo Molnar wrote:
> sorry but that's precisely what your suggestion above results in:
I'm not trying to suggest we "fake" anything. Your just misunderstanding
me.. I'm am suggesting we change LOC to something readable. If you think
we're "faking" something by d
On Tue, 2007-02-06 at 23:56 +0100, Ingo Molnar wrote:
> changing the current 'timer' entry (which is line 2 of /proc/interrupts)
> to be 'listed as lapic-timer' and to 'replace it with the count from
> LOC' is faking a count in a line where nothing like that should be.
This point is getting irr
301 - 400 of 808 matches
Mail list logo
