On Fri, 25 May 2007, Ingo Molnar wrote:
>
> sure enough, i'll work something sane out - i already have it partly
> split up. It will probably be something along the lines of: 'remove
> stuff that we can remove and still have functional scheduling' followed
> by an 'add minimal CFS patch' and
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> Ingo: to make things easier, the _best_ split-up would be not "this is
> the historical series of patches leading up to CFS v15" or something
> like that, but it would be nice to get that final CFS version as a
> series of patches that do some spec
On Fri, May 25, 2007 at 09:49:38AM -0700, Linus Torvalds wrote:
>
>
> On Fri, 25 May 2007, Ingo Molnar wrote:
> >
> > ok - then please merge that single hunk into the paravirtops patch - and
> > leave the other 6 hunks in this patch.
>
> Note: I'm actually much more interested in applying the
On Fri, 25 May 2007, Ingo Molnar wrote:
>
> ok - then please merge that single hunk into the paravirtops patch - and
> leave the other 6 hunks in this patch.
Note: I'm actually much more interested in applying the scheduler changes
than the paravirt-ops changes. It looks like CFS is getting s
> I wonder if this was the source of the lockdep selftest failures, or the
> mystery hang this patch caused (IIRC)..
No, the inbalance was just on the ftp server for an hour or so.
I doubt anybody except Ingo ever saw that code.
I introduced it while changing the callbacks around to make the code
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 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 hadn't spotted that
preempt_count() imbalance then there's a decent ch
On Fri, May 25, 2007 at 02:02:28PM +0200, Ingo Molnar wrote:
>
> * Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> > > find below the cleanups from my first patch that didnt make it into
> > > your cleanups. (plus one more cleanup i noticed while merging the
> > > missing bits from my first patch) Go
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> > find below the cleanups from my first patch that didnt make it into
> > your cleanups. (plus one more cleanup i noticed while merging the
> > missing bits from my first patch) Goes after the bugfix i just sent.
> > Please apply.
>
> I cannot apply i
On Fri, May 25, 2007 at 01:50:04PM +0200, Ingo Molnar wrote:
>
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > * Andi Kleen <[EMAIL PROTECTED]> wrote:
> >
> > > > please send me your current sched-clock.c, i'll redo any remaining
> > > > cleanups.
> > >
> > > It needs at least one new prelimi
On Fri, May 25, 2007 at 10:16:39AM +0200, Peter Zijlstra wrote:
> On Fri, 2007-05-25 at 09:58 +0200, Andi Kleen wrote:
> > On Fri, May 25, 2007 at 09:39:33AM +0200, Peter Zijlstra wrote:
> > > On Fri, 2007-05-25 at 13:05 +0530, Satyam Sharma wrote:
> > > > On 5/25/07, Ingo Molnar <[EMAIL PROTECTED]
On Fri, 2007-05-25 at 09:49 +0200, Ingo Molnar wrote:
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > updated version of the cleanup patch below, renamed r_s_c to
> > resync_freq, and changed 'f' to 'freq'.
>
> updated one below.
>
> Ingo
>
> --->
> Subject: [patch] sche
On Fri, 2007-05-25 at 09:58 +0200, Andi Kleen wrote:
> On Fri, May 25, 2007 at 09:39:33AM +0200, Peter Zijlstra wrote:
> > On Fri, 2007-05-25 at 13:05 +0530, Satyam Sharma wrote:
> > > On 5/25/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> >
> > > > call_r_s_f() still needs an urgent rerenaming thou
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> Propose a better way to code this then? It's not my fault that dealing
> with callbacks in C is so messy. _here just massages one callback
> prototype (smp_call_function's) into another (cpufreq's) because both
> callbacks do the same in this case.
se
On Fri, May 25, 2007 at 09:39:33AM +0200, Peter Zijlstra wrote:
> On Fri, 2007-05-25 at 13:05 +0530, Satyam Sharma wrote:
> > On 5/25/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > > call_r_s_f() still needs an urgent rerenaming though =B-)
> >
> > So does "call_r_s_f_here()" :-)
>
> That name
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> updated version of the cleanup patch below, renamed r_s_c to
> resync_freq, and changed 'f' to 'freq'.
updated one below.
Ingo
--->
Subject: [patch] sched_clock(): cleanups
From: Ingo Molnar <[EMAIL PROTECTED]>
clean up sched
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > Admittedly the second test could be inside a block of the first, but
> > then it would make the code more ugly and this code is not
> > performance critical.
>
> moving it inside the block makes the code _cleaner_ in fact :-)
updated version of the
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> > if (!f)
> > f = cpufreq_get(freq->cpu);
> > if (!f)
> > f = tsc_khz;
> >
> > ?
> >
> > Something's not quite right here :-)
>
> What do you think is wrong? cpufreq_get can return 0.
>
> Admittedly the second test could be inside a block of t
On Fri, 2007-05-25 at 13:05 +0530, Satyam Sharma wrote:
> On 5/25/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > call_r_s_f() still needs an urgent rerenaming though =B-)
>
> So does "call_r_s_f_here()" :-)
That name makes me think of INTERCAL's 'DO COME FROM' statement.
And any code that makes
On Fri, May 25, 2007 at 09:26:41AM +0200, Ingo Molnar wrote:
>
> > > if (!f)
> > > f = cpufreq_get(freq->cpu);
> > > if (!f)
> > > f = tsc_khz;
> > >
> > > ?
> > >
> > > Something's not quite right here :-)
>
> ah, that's fine. It does this: 'try to give f a value', and then: 'if
> still n
On 5/25/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > if (!f)
> > f = cpufreq_get(freq->cpu);
> > if (!f)
> > f = tsc_khz;
> >
> > ?
> >
> > Something's not quite right here :-)
ah, that's fine. It does this: 'try to give f a value', and then: 'if
still no value then give it tsc_khz as
> if (!f)
> f = cpufreq_get(freq->cpu);
> if (!f)
> f = tsc_khz;
>
> ?
>
> Something's not quite right here :-)
What do you think is wrong? cpufreq_get can return 0.
Admittedly the second test could be inside a block of the first,
but then it would make the code more ugly and this c
> > if (!f)
> > f = cpufreq_get(freq->cpu);
> > if (!f)
> > f = tsc_khz;
> >
> > ?
> >
> > Something's not quite right here :-)
ah, that's fine. It does this: 'try to give f a value', and then: 'if
still no value then give it tsc_khz as a last resort)
call_r_s_f() still needs an urgen
* Satyam Sharma <[EMAIL PROTECTED]> wrote:
> Hi Ingo,
>
> On 5/25/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> >[...]
> >@@ -137,6 +147,7 @@ static void call_r_s_f(void *arg)
> > {
> >struct cpufreq_freqs *freq = arg;
> >unsigned f = freq->new;
> >+
> >if (!f)
> >
Hi Ingo,
On 5/25/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
[...]
@@ -137,6 +147,7 @@ static void call_r_s_f(void *arg)
{
struct cpufreq_freqs *freq = arg;
unsigned f = freq->new;
+
if (!f)
f = cpufreq_get(freq->cpu);
if (!f)
if (!f)
f =
25 matches
Mail list logo