On Thu, 2007-07-12 at 17:37 +0200, Ingo Molnar wrote:
> We are pleased to announce something we've been working on for some
> time: a finegrained, split-up patch queue of the -rt kernel patch. From
> now on (as of 2.6.22.1-rt2) it will be part of every upstream -rt
> release and it is available
On Thu, 2007-07-12 at 17:37 +0200, Ingo Molnar wrote:
> We are pleased to announce something we've been working on for some
> time: a finegrained, split-up patch queue of the -rt kernel patch. From
> now on (as of 2.6.22.1-rt2) it will be part of every upstream -rt
> release and it is available
On Thu, 2007-07-12 at 19:01 +0200, Thomas Gleixner wrote:
> We know very well and Ingo nowhere said, that this is not a perfect
> queue, but it was and still is _our_ work base and we opened it up for
> the reasons explained.
Easy Thomas .. I was just trying to be helpful ..
> What we definitely
On Thu, 2007-07-12 at 20:40 +0200, Thomas Gleixner wrote:
> On Thu, 2007-07-12 at 10:02 -0700, Daniel Walker wrote:
> > On Thu, 2007-07-12 at 19:01 +0200, Thomas Gleixner wrote:
> >
> > > We know very well and Ingo nowhere said, that this is not a perfect
> > &g
.
Comment are certainly welcome ..
Signed-Off-By: Daniel Walker <[EMAIL PROTECTED]>
---
Against 2.6.22-rc2
arch/i386/kernel/tsc.c | 128
include/linux/clocksource.h | 14 +++-
2 files changed, 72 insertions(+), 70
Just passing a string to mark_tsc_unstable() doesn't allow real code to change
based on the reason for the instablility. I changed mark_tsc_unstable()
to accept a string and a flag which denotes a general reason why the tsc
is unstable, and can be evaluated in code.
Signed-Off-By: Daniel W
On Fri, 2007-05-25 at 23:05 +0200, Andi Kleen wrote:
> On Fri, May 25, 2007 at 12:32:10PM -0700, Daniel Walker wrote:
> > Just passing a string to mark_tsc_unstable() doesn't allow real code to
> > change
> > based on the reason for the instablility. I changed mark_tsc_
On Tue, 2007-05-29 at 14:52 +0200, Peter Zijlstra wrote:
> + now = sched_clock();
> + waittime = now - hlock->waittime_stamp;
> +
It looks like your using sched_clock() through out .. It's a little
troubling considering the constraints on the function .. Most
architecture implement a
On Wed, 2007-05-30 at 15:24 +0200, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > [...] Most architecture implement a jiffies sched_clock() w/ 1
> > millisecond or worse resolution.. [...]
>
> weird that you count importance by 'number
On Wed, 2007-05-30 at 15:49 +0200, Ingo Molnar wrote:
> * Steven Rostedt <[EMAIL PROTECTED]> wrote:
>
> > [...] We can argue that sched_clock is "good enough". If someone
> > wants better accounting of locks on some other arch, they can simply
> > change sched_clock to be more precise.
>
> exa
On Wed, 2007-05-30 at 19:16 +0200, Peter Zijlstra wrote:
> > >From the architecture perspective there are two low level clock hooks to
> > implement one is sched_clock() , and at least one clocksource structure.
> > Both do essentially the same thing. With timekeepings clocksource
> > structure ac
On Fri, 2007-06-01 at 15:12 +0200, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > On Wed, 2007-05-30 at 19:16 +0200, Peter Zijlstra wrote:
>
> > > I think you are mistaken here; the two are similar but not
> > > identical.
> &g
On Fri, 2007-06-01 at 17:52 +0200, Peter Zijlstra wrote:
> On Fri, 2007-06-01 at 08:26 -0700, Daniel Walker wrote:
> > On Fri, 2007-06-01 at 15:12 +0200, Ingo Molnar wrote:
> > > * Daniel Walker <[EMAIL PROTECTED]> wrote:
> > >
> > > > On Wed, 20
On Fri, 2007-06-01 at 20:19 +0200, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > > > > I see sched_clock() as fast first, accurate second. Whereas the
> > > > > clocksource thing is accurate first, fast second.
> > > >
On Fri, 2007-06-01 at 20:30 +0200, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > > So, having two interfaces, one fast and one accurate is the right
> > > answer IMHO.
> >
> > In the case of lockstat you have two cases fa
On Fri, 2007-06-01 at 20:43 +0200, Peter Zijlstra wrote:
> On Fri, 2007-06-01 at 09:11 -0700, Daniel Walker wrote:
> > On Fri, 2007-06-01 at 17:52 +0200, Peter Zijlstra wrote:
>
> > > The whole issue is that you don't have any control over what clocksource
> >
On Sat, 2007-07-14 at 19:57 +0200, Peter Zijlstra wrote:
> ===
> ---
> linux-2.6.22-rc6-mm1.orig/include/asm-generic/local.h 2007-07-12
> 19:44:18.0 -0700
> +++ linux-2.6.22-rc6-mm1/include/asm-generic/local.h2007-07-
On Thu, 2007-07-19 at 11:54 +0200, Andi Kleen wrote:
> Move it into an own file for easy sharing.
> Do everything per CPU. This avoids problems with TSCs that
> tick at different frequencies per CPU.
> Resync properly on cpufreq changes. CPU frequency is instable
> around cpu frequency changing, so
On Thu, 2007-07-19 at 19:13 +0200, Andi Kleen wrote:
> > What about using the cycles2ns() clocksource helpers, it would eliminate
> > the duplication of the shift/multiply math .
>
> They are completely different from what clocksource provides.
How so?
Daniel
-
To unsubscribe from this list: se
On Thu, 2007-07-19 at 19:22 +0200, Andi Kleen wrote:
> On Thursday 19 July 2007 19:15:38 Daniel Walker wrote:
> > On Thu, 2007-07-19 at 19:13 +0200, Andi Kleen wrote:
> > > > What about using the cycles2ns() clocksource helpers, it would eliminate
> > > > the dupli
On Thu, 2007-07-19 at 19:38 +0200, Andi Kleen wrote:
> On Thursday 19 July 2007 19:31:56 Daniel Walker wrote:
>
> > >From my perspective a downside to sched_clock is that the math is
> > duplicated per architecture .. I think it would be a win to use the
> > generic
On Thu, 2007-07-19 at 20:00 +0200, Andi Kleen wrote:
> On Thursday 19 July 2007 19:43:49 Daniel Walker wrote:
> > On Thu, 2007-07-19 at 19:38 +0200, Andi Kleen wrote:
> > > On Thursday 19 July 2007 19:31:56 Daniel Walker wrote:
> > >
> > > > >From my per
Switch to the defines for these two checks, instead of hard
coding the values.
Signed-Off-By: Daniel Walker <[EMAIL PROTECTED]>
---
kernel/sys.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: linux-2.6.21/kernel
.
Comment are certainly welcome ..
Signed-Off-By: Daniel Walker <[EMAIL PROTECTED]>
---
arch/i386/kernel/tsc.c | 130 +---
include/linux/clocksource.h | 14 +++-
2 files changed, 74 insertions(+), 70
tultz patch to add the string reasons.
Signed-Off-By: Daniel Walker <[EMAIL PROTECTED]>
---
arch/i386/kernel/cpu/cyrix.c|9 --
arch/i386/kernel/tsc.c | 39 +---
arch/x86_64/kernel/time.c |3 +-
On Sat, 2007-05-12 at 20:56 +0200, Andi Kleen wrote:
> On Saturday 12 May 2007 17:43:45 Daniel Walker wrote:
> > Just passing a string to mark_tsc_unstable() doesn't allow real code to
> > change
> > based on the reason for the instablility. I changed mark_tsc_unstabl
On Sat, 2007-05-12 at 20:58 +0200, Andi Kleen wrote:
> On Saturday 12 May 2007 17:43:46 Daniel Walker wrote:
> > Considering that Andi has a similar patch, I'm going to assume there
> > is already justification for this..
>
> I just have a patch for sched_clock, w
On Sun, 2007-05-13 at 03:18 +0400, Stas Sergeev wrote:
> Hello.
>
> Without the attached patch, I wasn't able
> to get the PIT to work as a clocksource for
> high-res timers.
> I don't know whether the patch is correct,
> but I tested it and it works.
> Can someone please tell me what exactly
> do
On Wed, 2007-05-16 at 20:04 +0200, Ingo Molnar wrote:
> i'm pleased to announce the v2.6.20-rt2 kernel, which can be downloaded
> from the usual place:
2.6.21-rt2 ?
> http://redhat.com/~mingo/realtime-preempt/
>
> more info about the -rt patchset can be fo
On Wed, 2007-05-16 at 23:01 +0200, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > On Wed, 2007-05-16 at 20:04 +0200, Ingo Molnar wrote:
> > > i'm pleased to announce the v2.6.20-rt2 kernel, which can be downloaded
> > > from the usu
On Wed, 2007-05-16 at 23:32 +0200, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > > > http://lkml.org/lkml/2007/5/3/368
> > >
> > > hm - trace_hardirqs_on() should never be called with irqs on -
> > > lockdep could br
On Thu, 2007-05-17 at 00:04 +0200, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > I don't know. irqs_off_preempt_count() could get used someplace else,
> > where you would want to flip the preempt_count() check .. It seems
> > s
On Fri, 2007-06-29 at 09:09 +0200, Michel Dänzer wrote:
> I just read an article on LWN's kernel page about plans to remove
> tasklets, and I thought I'd explain what the DRM is using tasklets for.
> Maybe there's other ways to satisfy the requirements equally well or
> even better.
>
>
> The i91
On Thu, 2007-05-17 at 13:17 -0500, Kumar Gala wrote:
>
> I haven't looked at all the new clock/timer code, is there any
> utility in having support for more than one clock source?
There is if the main clocksource has some issues where it can't be used.
On x86 there are lots of different issues
On Fri, 2007-05-18 at 19:06 +0400, Sergei Shtylyov wrote:
> Daniel Walker wrote:
>
> >>I haven't looked at all the new clock/timer code, is there any
> >>utility in having support for more than one clock source?
>
> > There is if the main clocksource
On Sat, 2007-05-19 at 13:33 +1000, Paul Mackerras wrote:
> Daniel Walker writes:
>
> > On Fri, 2007-05-18 at 19:06 +0400, Sergei Shtylyov wrote:
> > > Well, the decrementer frequency may change, at least in theory (if
> > > the bus
> > > clock changes
Where did the arm ep93xx changes come from? It looks like patch below
came in with them in 2.6.21-rt6 ..
--- linux.orig/include/asm-arm/system.h
+++ linux/include/asm-arm/system.h
@@ -235,8 +235,9 @@ static inline void set_copro_access(unsi
* so enable interrupts over the context switch to avoi
On Mon, 2007-05-21 at 22:24 +0200, Thomas Gleixner wrote:
> On Mon, 2007-05-21 at 13:11 -0700, Daniel Walker wrote:
> > Where did the arm ep93xx changes come from?
>
> Grown out of my nose probably.
>
> > It looks like patch below
> > came in with them in 2.6.
On Mon, 2007-05-21 at 22:36 +0200, Thomas Gleixner wrote:
> On Mon, 2007-05-21 at 13:25 -0700, Daniel Walker wrote:
> > On Mon, 2007-05-21 at 22:24 +0200, Thomas Gleixner wrote:
> > > On Mon, 2007-05-21 at 13:11 -0700, Daniel Walker wrote:
> > > > Where did th
On Tue, 2007-05-22 at 10:25 +0200, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > I copied the patch into the first email, I did look at it which is why
> > you got an email. Your introducing the patch , it's for you to explain
> > why
On Tue, 2007-05-22 at 16:01 -0700, Kevin Hilman wrote:
> Add a preempt_enable() to flush_tlb_kernel_page() since -rt4 patch
> adds a preempt_disable but no preempt_enable().
>
> Signed-off-by: Kevin Hilman <[EMAIL PROTECTED]>
>
>
> ---
> include/asm-arm/tlbflush.h |1 +
> 1 file changed, 1
On Tue, 2007-05-22 at 16:41 -0700, Kevin Hilman wrote:
>
> Individually, yes. But the point of the preempt_disable/enable is to
> make the whole sequence atomic.
I was under the impression that only one of those mcr lines is called
per board type, the rest just compile away?
Daniel
-
To unsu
On Wed, 2007-05-23 at 09:13 -0700, Kevin Hilman wrote:
> Note that my patch simply adds an enable to match the disable added by
> the -rt patch. I'm not sure where the disable originally came from, but
> there are disable/enable pairs scattered throughout tlbflush.h in the
> -rt patch.
>
> If th
On Fri, 2007-05-25 at 09:17 -0700, Andrew Morton wrote:
> On Fri, 25 May 2007 14:15:40 +0200 Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> > -Andi (who hopes this thread will end soon now and we can all go
> > back to more important issues)
>
> fyi, the thread has been damn useful for me. If Ingo ha
On Thu, 2007-03-08 at 15:55 -0800, Zachary Amsden wrote:
>
> We just don't drive the local timer interrupts through the APIC, we make
> hypercalls to schedule local timer alarms. Which is something we must
> do for UP kernels as well, which use the PIT / PIC. So there is a need
> for having
On Tue, 2007-03-13 at 13:32 -0700, Jeremy Fitzhardinge wrote:
> Most of the existing clocksource infrastructure would only operate on
> CLOCK_TIMEBASE_REALTIME clocksources, so I'm not sure how much overlap
> there would be here. In the case of dealing with cpufreq, there's a
> certain appeal to
On Tue, 2007-03-13 at 14:59 -0700, Jeremy Fitzhardinge wrote:
> Daniel Walker wrote:
> > The frequency tracking you mention is done to some extent inside the
> > timekeeping adjustment functions, but I'm not sure it's totally accurate
> > for non-timekeeping,
On Tue, 2007-03-13 at 23:52 -0700, Jeremy Fitzhardinge wrote:
> >
> > That's true, but given a constant clock (like what sched_clock should
> > have) then the accounting is similarly inaccurate. Any connection
> > between the scheduler and the TSC frequency changes aren't part of the
> > design AF
On Wed, 2007-03-14 at 09:37 -0700, Jeremy Fitzhardinge wrote:
> Daniel Walker wrote:
> > Then your direction is wrong, sched_clock() should be constant ideally
> > (1millisecond should really be 1millisecond).
>
> Rather than repeating myself, I suggest you read my original
On Wed, 2007-03-14 at 10:08 -0700, Jeremy Fitzhardinge wrote:
> The actual length of the timeslices is an orthogonal issue. It may be
> that you want to give processes more cpu time by making their quanta
> longer to compensate for lost cpu time, but that would affect their
> real-time characteri
On Wed, 2007-03-14 at 11:41 -0700, Jeremy Fitzhardinge wrote:
> Daniel Walker wrote:
> > >From prior emails I think your suggesting that 1ms (or 5 or 10) of time
> > should actually be a variable X that is changed inside sched_clock().
> > That's not the purpose
On Wed, 2007-03-14 at 12:44 -0700, Jeremy Fitzhardinge wrote:
> Daniel Walker wrote:
> > sched_clock is used to bank real time against some specific states
> > inside the scheduler, and no it doesn't _just_ measure a processes
> > executing time.
> >
>
>
On Wed, 2007-03-14 at 14:16 -0700, Jeremy Fitzhardinge wrote:
>
> > It's also used for some posix cpu timers
> > (sched_ns) , and it used for migration thread initialization.
>
> sched_ns doesn't use it directly except for the case where the process
> is currently running. Anyway, it's compati
On Fri, 2007-03-16 at 19:14 +0100, Guillaume Chazarain wrote:
> Hello,
>
> The scheduling problems I reported in the thread:
> http://lkml.org/lkml/2007/3/3/128
> are caused by the set_cyc2ns_scale() function called when the CPU speed
> changes.
> Changing the scale causes a warp in the value ret
Signed-Off-By: Daniel Walker <[EMAIL PROTECTED]>
---
include/linux/seqlock.h |8
1 file changed, 4 insertions(+), 4 deletions(-)
Index: linux-2.6.20/include/linux/seqlock.h
===
--- linux-2.6.20.orig/include
On Fri, 2007-04-13 at 22:21 +0200, Ingo Molnar wrote:
> [announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
>
> i'm pleased to announce the first release of the "Modular Scheduler Core
> and Completely Fair Scheduler [CFS]" patchset:
>
>http://redhat.com/~mingo/cfs-s
One other thing, what happens in the case of slow, frequency changing,
are/or inaccurate clocks .. Is the old sched_clock behavior still
tolerated?
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info
On Fri, 2007-05-04 at 12:26 +0200, Peter Zijlstra wrote:
> 1) introduce the memory reserve and make the SLAB allocator play nice with it.
>patches 01-10
>
> 2) add some needed infrastructure to the network code
>patches 11-13
>
> 3) implement the idea outlined above
>patches 14-20
>
On Fri, 2007-05-04 at 17:38 +0200, Peter Zijlstra wrote:
> >
> > This is kind of a lot of patches all at once .. Have you release any of
> > these patch sets prior to this release ?
>
> Like the -v12 suggests, this is the 12th posting of this patch set.
> Some is the same, some has changed.
I c
On Fri, 2007-05-04 at 14:09 -0400, Mike Snitzer wrote:
> On 5/4/07, Daniel Walker <[EMAIL PROTECTED]> wrote:
> > On Fri, 2007-05-04 at 17:38 +0200, Peter Zijlstra wrote:
> > > >
> > > > This is kind of a lot of patches all at once .. Have you release any of
On Mon, 2007-05-07 at 11:47 -0700, Tim Bird wrote:
> I've applied patch-2.6.21-rt1 to a 2.6.21 kernel I'm using.
> With the patch applied, but no RT-Preempt options enabled,
> I'm getting network failures (eth0 transmit timeouts) on
> an OMAP board.
Are you sure you don't have HardIRQS in Threads
On Mon, 2007-05-07 at 14:02 -0700, Tim Bird wrote:
> Daniel Walker wrote:
> > Are you sure you don't have HardIRQS in Threads enabled? Also are you
> > sure the kernel boots without the rt patch applied.
>
> Yes on both counts. I double-checked the configs. I'm us
Signed-Off-By: Daniel Walker <[EMAIL PROTECTED]>
---
kernel/time/clocksource.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.21/kernel/time/clocksource.c
===
--- linux-2.6.21.orig/kerne
Theres more that need fixing , and fix my own subject spelling
error too.
Signed-Off-By: Daniel Walker <[EMAIL PROTECTED]>
---
kernel/time/clocksource.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Index: linux-2.6.21/kernel/time/clockso
On Tue, 2007-03-20 at 10:58 -0700, john stultz wrote:
> > /* timekeeping specific data, ignore */
> > - cycle_t cycle_last, cycle_interval;
> > - u64 xtime_nsec, xtime_interval;
> > + cycle_t cycle_interval;
> > + u64 xtime_interval;
> > + /*
> > +* Second part is written at
On Wed, 2007-04-04 at 12:58 -0700, Andrew Morton wrote:
> On Wed, 04 Apr 2007 09:38:32 -0700
> Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > On Sun, 2007-04-01 at 10:43 +0200, Thomas Gleixner wrote:
> > > On Sat, 2007-03-31 at 22:23 -0700, [EMAIL PROTECTED] w
On Wed, 2007-04-04 at 22:36 +0200, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > The struct clocksource .list field is now required to be initialized
> > before calling clocksource_register().
> >
> > This is a prerequisite for simp
On Wed, 2007-04-04 at 23:15 +0200, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > > > This is a prerequisite for simplifying the clocksource
> > > > registration process.
> > >
> > > why? This patch only pushes som
On Wed, 2007-04-04 at 23:34 +0200, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > > but why do you call that a simplification? Remove 5 lines of code
> > > from the generic code, by adding +1 line to every clocksource
> > > dri
On Wed, 2007-04-04 at 16:48 -0700, Jeremy Fitzhardinge wrote:
> Daniel Walker wrote:
> > I vaguely remember, but I don't think this creates a maintenance
> > issue .. It's not related to maintenance , it's an issue of creating a
> > new clocksource .. My per
On Wed, 2007-04-04 at 17:20 -0700, Jeremy Fitzhardinge wrote:
> Daniel Walker wrote:
> > Setting CLOCK_SOURCE_IS_CONTINUOUS is largely administration , do you
> > know what that flag means?
> >
>
> Sure, but at least it has something to do with clocks and time.
On Thu, 2007-04-05 at 09:51 +0200, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > [...] Adding a list initializer doesn't change anything..
>
> Daniel, you are still in denial. OF COURSE it changes something: it adds
> a line of code to a
, compile tested on x86_64 .. However, I couldn't
find a !GENERIC_TIME that compiled without this change so it's untested..
Signed-Off-By: Daniel Walker <[EMAIL PROTECTED]>
---
include/linux/timekeeping.h | 10 ++
kernel/time/clocksource.c |7 +++
kernel/ti
On Thu, 2007-04-05 at 14:25 -0700, john stultz wrote:
> On Thu, 2007-04-05 at 14:03 -0700, Daniel Walker wrote:
> > Before this change the timekeeping code would poll the clocksource
> > list every interrupt. This changes that so the clocksource list is
> > only checked wh
On Fri, 2007-04-06 at 18:21 -0700, Andrew Morton wrote:
> On Thu, 05 Apr 2007 14:03:16 -0700 Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > Boot tested on i386, compile tested on x86_64 .. However, I couldn't
> > find a !GENERIC_TIME that compiled without this chang
On Sat, 2007-04-07 at 03:19 -0700, Andrew Morton wrote:
> On Thu, 05 Apr 2007 14:03:16 -0700 Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > Before this change the timekeeping code would poll the clocksource
> > list every interrupt. This changes that so the clocksource
On Sat, 2007-04-07 at 22:50 +0200, Thomas Gleixner wrote:
> On Sat, 2007-04-07 at 10:43 -0700, Daniel Walker wrote:
> > Looks like this path ,
> >
> > arch/i386/kernel/tsc.c: time_cpufreq_notifier(); <-- takes xtime_lock
> >
On Sun, 2007-04-08 at 10:33 +0200, Thomas Gleixner wrote:
>
> Oh well, this is a leftover from the days where we tried to use TSC
> despite of frequency changes. It still modifies the scale factor of the
> tsc clocksource.
>
> I agree that it can be removed as we switch off TSC anyway in that ca
Signed-Off-By: Daniel Walker <[EMAIL PROTECTED]>
---
drivers/clocksource/acpi_pm.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.20/drivers/clocksource/acpi_pm.c
===
--- linux-2.6.20.orig/d
once been used
for timekeeping, but not any longer ..
Signed-Off-By: Daniel Walker <[EMAIL PROTECTED]>
---
arch/i386/kernel/tsc.c |8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
Index: linux-2.6.20/arch/i386/kernel
to make it explicit .
Signed-Off-By: Daniel Walker <[EMAIL PROTECTED]>
---
kernel/sched.c | 31 ++-
1 file changed, 22 insertions(+), 9 deletions(-)
Index: linux-2.6.20/kernel/sched.c
===
--- linux-2.
On Wed, 2007-04-11 at 13:31 -0700, Andrew Morton wrote:
> On Wed, 11 Apr 2007 09:29:04 -0700
> Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > The locking of the xtime_lock around the cpu notifier is unessesary now. At
> > one
> > time the tsc was used after a
On Thu, 2007-04-12 at 10:43 -0700, Jeremy Fitzhardinge wrote:
> Andrew Morton wrote:
> > hm. People (ab)use sched_clock() for all sorts of things nowadays. I
> > wouldn't
> > do anything to degrade it just on behalf of printk-timestamping.
> >
>
> printk was the only non-scheduler-ish use I
On Tue, 2007-04-24 at 13:24 -0700, Jeremy Fitzhardinge wrote:
> And sched_clock's use of local_irq_save/restore appears to be absolutely
> correct, so I think it must be triggering a bug in either the self-tests
> or lockdep itself.
Why does sched_clock need to disable interrupts?
Daniel
-
To u
On Tue, 2007-04-24 at 22:59 +0200, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > On Tue, 2007-04-24 at 13:24 -0700, Jeremy Fitzhardinge wrote:
> >
> > > And sched_clock's use of local_irq_save/restore appears to be absolutel
On Tue, 2007-04-24 at 23:20 +0200, Andi Kleen wrote:
> On Tuesday 24 April 2007 22:52:27 Daniel Walker wrote:
> > On Tue, 2007-04-24 at 13:24 -0700, Jeremy Fitzhardinge wrote:
> >
> > > And sched_clock's use of local_irq_save/restore appears to be absolutely
> &g
These macros were a little confused looking, so I cleaned then up
a bit. I think this way it's a little clearer what's what ..
Signed-Off-By: Daniel Walker <[EMAIL PROTECTED]>
---
include/linux/posix-timers.h | 38 +++---
1 file changed, 27 i
On Thu, 2007-04-26 at 16:26 -0400, Peter Keilty wrote:
> +.mask = (1LL << 40) - 1,
> +.mult = 0, /*to be caluclated*/
> +.shift = 16,
> +.is_continuous = 1,
> };
You should use CLOCKSOURCE_MASK() here ..
>
> diff --git a/include/l
On Fri, 2007-04-27 at 10:38 -0400, Peter Keilty wrote:
> Daniel Walker wrote:
>
> >On Thu, 2007-04-26 at 16:26 -0400, Peter Keilty wrote:
> >
> >
> >
> >>+.mask = (1LL << 40) - 1,
> >>+.mult = 0,
On Fri, 2007-04-27 at 11:42 -0400, Peter Keilty wrote:
> >
> >There is a read(), and a vread() did you modify the slow syscall path to
> >use the vread()?
> >
> >
> I miss type, read().
John mentioned that he thought fsys_mmio_ptr could be held in the vread
pointer. vread() is used in x86 for v
On Fri, 2007-04-27 at 12:11 -0400, Peter Keilty wrote:
> >
> No, but yes it can be done, overloading the meaning.
> It would need to change in the future if vread was needed.
> I have no strong argument against using it.
> Although we may still need the IA64 define, I removed 32bit read mmio and
On Fri, 2007-03-02 at 15:24 -0800, john stultz wrote:
> Thus the solution here is to register clocksources earlier (ideally when
> the hardware is being initialized), and then we enable clocksource
> selection at fs_initcall (before device_initcall).
>
When I was doing this in my tree I found th
ents)
> > > References : http://lkml.org/lkml/2007/2/21/208
> > > Submitter : Daniel Walker <[EMAIL PROTECTED]>
> > > Caused-By : Thomas Gleixner <[EMAIL PROTECTED]>
> > > commit e9e2cdb412412326c4827fc78ba27f410d837e6e
> > > Hand
On Mon, 2007-03-05 at 16:27 +0100, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > > > FYI, this is not a "wont boot" problem, this should be a "NMI
> > > > watchdog does not work" problem - which has far lower severit
ttimeofday(), that way
the vsyscall state doesn't get stale.
Any thought John?
Signed-Off-By: Daniel Walker <[EMAIL PROTECTED]>
---
kernel/timer.c |2 ++
1 file changed, 2 insertions(+)
Index: linux-2.6.20/kernel/timer.c
===
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(+)
Update arch/s390 with list initialization.
Signed-Off-By: Daniel Walker <[EMAIL PROTECTED]>
---
arch/s390/kernel/time.c |1 +
1 file changed, 1 insertion(+)
Index: linux-2.6.20/arch/s390/kernel/time.c
===
--- linux-2.6.2
-By: Daniel Walker <[EMAIL PROTECTED]>
---
include/linux/clocksource.h |2 +-
kernel/time/clocksource.c | 30 ++
kernel/time/jiffies.c |1 +
3 files changed, 20 insertions(+), 13 deletions(-)
Index: linux-2.6.20/include/linux/clockso
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/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.20/arch/x86_64/kernel/
501 - 600 of 808 matches
Mail list logo
