On Wed, 4 Jun 2014, Olof Johansson wrote:
> On Wed, Jun 4, 2014 at 3:49 AM, Thomas Gleixner wrote:
> So, we'll dial back and stop taking these patches through our tree
> without an explicit ack or shared branch from you (or Daniel on
> clocksource). Not a problem at all.
I prefer the shared
On Wed, Jun 4, 2014 at 3:49 AM, Thomas Gleixner wrote:
> On Wed, 4 Jun 2014, Stephen Rothwell wrote:
>
>> Hi all,
>>
>> After merging the tip tree, today's linux-next build (arm
>> multi_v7_defconfig) failed like this:
>>
>>
>> drivers/clocksource/versatile.c: In function
On Wed, Jun 4, 2014 at 3:49 AM, Thomas Gleixner wrote:
>
> Patch below. Linus, can you please apply this?
Done.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
On Wed, 4 Jun 2014, Stephen Rothwell wrote:
> Hi all,
>
> After merging the tip tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
>
> drivers/clocksource/versatile.c: In function 'versatile_sched_clock_init':
> drivers/clocksource/versatile.c:37:2: error: implicit
Hi all,
After merging the tip tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
drivers/clocksource/versatile.c: In function 'versatile_sched_clock_init':
drivers/clocksource/versatile.c:37:2: error: implicit declaration of function
'setup_sched_clock'
Hi all,
After merging the tip tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
drivers/clocksource/versatile.c: In function 'versatile_sched_clock_init':
drivers/clocksource/versatile.c:37:2: error: implicit declaration of function
'setup_sched_clock'
On Wed, 4 Jun 2014, Stephen Rothwell wrote:
Hi all,
After merging the tip tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
drivers/clocksource/versatile.c: In function 'versatile_sched_clock_init':
drivers/clocksource/versatile.c:37:2: error: implicit
On Wed, Jun 4, 2014 at 3:49 AM, Thomas Gleixner t...@linutronix.de wrote:
Patch below. Linus, can you please apply this?
Done.
Linus
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at
On Wed, Jun 4, 2014 at 3:49 AM, Thomas Gleixner t...@linutronix.de wrote:
On Wed, 4 Jun 2014, Stephen Rothwell wrote:
Hi all,
After merging the tip tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
drivers/clocksource/versatile.c: In function
On Wed, 4 Jun 2014, Olof Johansson wrote:
On Wed, Jun 4, 2014 at 3:49 AM, Thomas Gleixner t...@linutronix.de wrote:
So, we'll dial back and stop taking these patches through our tree
without an explicit ack or shared branch from you (or Daniel on
clocksource). Not a problem at all.
I prefer
Hi Russell,
On Fri, 23 May 2014 17:14:12 +1000 Stephen Rothwell
wrote:
>
> After merging the tip tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> In file included from arch/arm/include/asm/outercache.h:24:0,
> from
Hi Russell,
On Fri, 23 May 2014 17:14:12 +1000 Stephen Rothwell s...@canb.auug.org.au
wrote:
After merging the tip tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
In file included from arch/arm/include/asm/outercache.h:24:0,
from
Hi all,
After merging the tip tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
In file included from arch/arm/include/asm/outercache.h:24:0,
from arch/arm/include/asm/barrier.h:5,
from arch/arm/include/asm/bitops.h:28,
Hi all,
After merging the tip tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
In file included from arch/arm/include/asm/outercache.h:24:0,
from arch/arm/include/asm/barrier.h:5,
from arch/arm/include/asm/bitops.h:28,
Hi all,
After merging the tip tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
In file included from arch/arm/include/asm/outercache.h:24:0,
from arch/arm/include/asm/barrier.h:5,
from arch/arm/include/asm/bitops.h:28,
Hi all,
After merging the tip tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
In file included from arch/arm/include/asm/outercache.h:24:0,
from arch/arm/include/asm/barrier.h:5,
from arch/arm/include/asm/bitops.h:28,
Hi Stephen,
On 02/12/2014 08:11 AM, Stephen Rothwell wrote:
> Hi all,
>
> After merging the tip tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> drivers/cpuidle/cpuidle-pseries.c: In function 'idle_loop_prolog':
> drivers/cpuidle/cpuidle-pseries.c:32:2: error:
Hi all,
After merging the tip tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
drivers/cpuidle/cpuidle-pseries.c: In function 'idle_loop_prolog':
drivers/cpuidle/cpuidle-pseries.c:32:2: error: implicit declaration of function
'ppc64_runlatch_off'
Hi all,
After merging the tip tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
drivers/cpuidle/cpuidle-pseries.c: In function 'idle_loop_prolog':
drivers/cpuidle/cpuidle-pseries.c:32:2: error: implicit declaration of function
'ppc64_runlatch_off'
Hi Stephen,
On 02/12/2014 08:11 AM, Stephen Rothwell wrote:
Hi all,
After merging the tip tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
drivers/cpuidle/cpuidle-pseries.c: In function 'idle_loop_prolog':
drivers/cpuidle/cpuidle-pseries.c:32:2: error: implicit
Hi all,
After merging the tip tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
arch/powerpc/platforms/cell/spufs/sched.c:86:0: error: "MAX_USER_PRIO"
redefined [-Werror]
#define MAX_USER_PRIO (MAX_PRIO - MAX_RT_PRIO)
^
In file included from
Hi all,
After merging the tip tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
arch/powerpc/platforms/cell/spufs/sched.c:86:0: error: MAX_USER_PRIO
redefined [-Werror]
#define MAX_USER_PRIO (MAX_PRIO - MAX_RT_PRIO)
^
In file included from include/linux/sched.h:6:0,
* Peter Zijlstra wrote:
> On Mon, Jan 20, 2014 at 04:39:45PM -0500, Len Brown wrote:
> > > As a side note, at minimum the semantic and compatibility difference
> > > needs to be _very_ clearly present in the naming. Something like
> > > mwait_old_() or mwait_core2_(). That way such dependencies
* Peter Zijlstra pet...@infradead.org wrote:
On Mon, Jan 20, 2014 at 04:39:45PM -0500, Len Brown wrote:
As a side note, at minimum the semantic and compatibility difference
needs to be _very_ clearly present in the naming. Something like
mwait_old_() or mwait_core2_(). That way such
On Mon, 2014-01-20 at 22:51 +0100, Peter Zijlstra wrote:
> I'm still waiting for someone to explain what's wrong with:
>
> static inline void mwait_idle(void)
> {
> local_irq_enable();
> mwait_idle_with_hints(0, 0);
> }
How about just do that going forward, it work, and can always
On Mon, Jan 20, 2014 at 04:39:45PM -0500, Len Brown wrote:
> > As a side note, at minimum the semantic and compatibility difference
> > needs to be _very_ clearly present in the naming. Something like
> > mwait_old_() or mwait_core2_(). That way such dependencies and
> > assumptions don't get lost
> As a side note, at minimum the semantic and compatibility difference
> needs to be _very_ clearly present in the naming. Something like
> mwait_old_() or mwait_core2_(). That way such dependencies and
> assumptions don't get lost in code restructuring, etc.
Agreed.
We started with mwait_idle()
On Mon, Jan 20, 2014 at 2:10 PM, Stephen Rothwell wrote:
> Hi Sedat,
>
> On Mon, 20 Jan 2014 09:46:55 +0100 Sedat Dilek wrote:
>>
>> On Mon, Jan 20, 2014 at 9:42 AM, Sedat Dilek wrote:
>> > On Mon, Jan 20, 2014 at 4:51 AM, Stephen Rothwell
>> > wrote:
>> >> On Sat, 18 Jan 2014 10:46:06 +0100
Hi Sedat,
On Mon, 20 Jan 2014 09:46:55 +0100 Sedat Dilek wrote:
>
> On Mon, Jan 20, 2014 at 9:42 AM, Sedat Dilek wrote:
> > On Mon, Jan 20, 2014 at 4:51 AM, Stephen Rothwell
> > wrote:
> >> On Sat, 18 Jan 2014 10:46:06 +0100 Mike Galbraith
> >> wrote:
> >>>
> >>> I hope it doesn't look
On Mon, Jan 20, 2014 at 02:19:30AM -0800, H. Peter Anvin wrote:
> On 01/20/2014 02:13 AM, Peter Zijlstra wrote:
> > On Mon, Jan 20, 2014 at 09:30:21AM +0100, Peter Zijlstra wrote:
> >> Then make them so. The fact was that most of the mwait idle sites
> >> were bloody broken. And the single
On Mon, Jan 20, 2014 at 03:00:29AM -0800, H. Peter Anvin wrote:
> On 01/20/2014 01:55 AM, Peter Zijlstra wrote:
> >
> > Ok, so I still don't get the problem of enabling interrupts early.
> >
> > If we enable them early we can get interrupts; which afaict fall into
> > two groups, those that do
On 01/20/2014 01:55 AM, Peter Zijlstra wrote:
>
> Ok, so I still don't get the problem of enabling interrupts early.
>
> If we enable them early we can get interrupts; which afaict fall into
> two groups, those that do and do not set NEED_RESCHED.
>
> For those that do not set NEED_RESCHED,
On 01/20/2014 02:13 AM, Peter Zijlstra wrote:
> On Mon, Jan 20, 2014 at 09:30:21AM +0100, Peter Zijlstra wrote:
>> Then make them so. The fact was that most of the mwait idle sites
>> were bloody broken. And the single mwait_idle_with_hints() function
>> presents a single nice function that does
On Mon, Jan 20, 2014 at 09:30:21AM +0100, Peter Zijlstra wrote:
> Then make them so. The fact was that most of the mwait idle sites
> were bloody broken. And the single mwait_idle_with_hints() function
> presents a single nice function that does all the required magics.
To stress this a bit more;
On Mon, Jan 20, 2014 at 01:23:00AM -0800, H. Peter Anvin wrote:
> On 01/20/2014 01:16 AM, Peter Zijlstra wrote:
> >>
> >> The difference is the STI!
> >
> > So do the local_irq_enable(); mwait_idle_with_hints(0,0); thing.
> >
>
> No, that doesn't work. The point of __sti_mwait() is that the
On Mon, 2014-01-20 at 10:25 +0100, Sedat Dilek wrote:
> It's about the handling of fixes for -next.
Ah, it was a gripe in query form. My bad.
-Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo
* H. Peter Anvin wrote:
> On 01/20/2014 01:16 AM, Peter Zijlstra wrote:
> >>
> >> The difference is the STI!
> >
> > So do the local_irq_enable(); mwait_idle_with_hints(0,0); thing.
> >
>
> No, that doesn't work. The point of __sti_mwait() is that the STI
> is the instruction immediately
On Mon, Jan 20, 2014 at 10:17 AM, Mike Galbraith wrote:
> On Mon, 2014-01-20 at 09:42 +0100, Sedat Dilek wrote:
>> On Mon, Jan 20, 2014 at 4:51 AM, Stephen Rothwell
>> wrote:
>> > On Sat, 18 Jan 2014 10:46:06 +0100 Mike Galbraith
>> > wrote:
>> >>
>> >> I hope it doesn't look quite like that,
On 01/20/2014 01:16 AM, Peter Zijlstra wrote:
>>
>> The difference is the STI!
>
> So do the local_irq_enable(); mwait_idle_with_hints(0,0); thing.
>
No, that doesn't work. The point of __sti_mwait() is that the STI is
the instruction immediately before the MWAIT, just like the combination
On Mon, 2014-01-20 at 09:42 +0100, Sedat Dilek wrote:
> On Mon, Jan 20, 2014 at 4:51 AM, Stephen Rothwell
> wrote:
> > On Sat, 18 Jan 2014 10:46:06 +0100 Mike Galbraith
> > wrote:
> >>
> >> I hope it doesn't look quite like that, next-20140117 is -ENOBOOT on
> >> Q6600 box. See below for an
On Mon, Jan 20, 2014 at 12:56:47AM -0800, H. Peter Anvin wrote:
> On 01/20/2014 12:26 AM, Peter Zijlstra wrote:
> > On Sun, Jan 19, 2014 at 11:45:43PM -0500, Len Brown wrote:
> >> +static void mwait_idle(void)
> >> +{
> >> + mwait_idle_with_hints(0, 0);
> >> +}
> >> +
> >>
> >> The reason
On 01/20/2014 12:26 AM, Peter Zijlstra wrote:
> On Sun, Jan 19, 2014 at 11:45:43PM -0500, Len Brown wrote:
>> +static void mwait_idle(void)
>> +{
>> + mwait_idle_with_hints(0, 0);
>> +}
>> +
>>
>> The reason the patch above will crash Core2 machines is because
>> core2 machines don't support
On Mon, Jan 20, 2014 at 9:42 AM, Sedat Dilek wrote:
> On Mon, Jan 20, 2014 at 4:51 AM, Stephen Rothwell
> wrote:
>> On Sat, 18 Jan 2014 10:46:06 +0100 Mike Galbraith
>> wrote:
>>>
>>> I hope it doesn't look quite like that, next-20140117 is -ENOBOOT on
>>> Q6600 box. See below for an
On Mon, Jan 20, 2014 at 4:51 AM, Stephen Rothwell wrote:
> On Sat, 18 Jan 2014 10:46:06 +0100 Mike Galbraith wrote:
>>
>> I hope it doesn't look quite like that, next-20140117 is -ENOBOOT on
>> Q6600 box. See below for an alternative.
>>
>> idle: kill unnecessary mwait_idle() resched IPIs
>
>
On Sun, Jan 19, 2014 at 08:00:19PM -0500, Len Brown wrote:
> On Wed, Jan 15, 2014 at 10:58 PM, Stephen Rothwell
> wrote:
> > Hi all,
> >
> > After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> > failed like this:
> >
> > arch/x86/kernel/process.c: In function
On Sun, Jan 19, 2014 at 11:45:43PM -0500, Len Brown wrote:
> +static void mwait_idle(void)
> +{
> + mwait_idle_with_hints(0, 0);
> +}
> +
>
> The reason the patch above will crash Core2 machines is because
> core2 machines don't support mwait_idle_with_hints().
>
> The calling sequence for
Hi Sedat,
On Mon, 20 Jan 2014 09:46:55 +0100 Sedat Dilek sedat.di...@gmail.com wrote:
On Mon, Jan 20, 2014 at 9:42 AM, Sedat Dilek sedat.di...@gmail.com wrote:
On Mon, Jan 20, 2014 at 4:51 AM, Stephen Rothwell s...@canb.auug.org.au
wrote:
On Sat, 18 Jan 2014 10:46:06 +0100 Mike Galbraith
On Mon, Jan 20, 2014 at 2:10 PM, Stephen Rothwell s...@canb.auug.org.au wrote:
Hi Sedat,
On Mon, 20 Jan 2014 09:46:55 +0100 Sedat Dilek sedat.di...@gmail.com wrote:
On Mon, Jan 20, 2014 at 9:42 AM, Sedat Dilek sedat.di...@gmail.com wrote:
On Mon, Jan 20, 2014 at 4:51 AM, Stephen Rothwell
As a side note, at minimum the semantic and compatibility difference
needs to be _very_ clearly present in the naming. Something like
mwait_old_() or mwait_core2_(). That way such dependencies and
assumptions don't get lost in code restructuring, etc.
Agreed.
We started with mwait_idle() --
On Mon, Jan 20, 2014 at 04:39:45PM -0500, Len Brown wrote:
As a side note, at minimum the semantic and compatibility difference
needs to be _very_ clearly present in the naming. Something like
mwait_old_() or mwait_core2_(). That way such dependencies and
assumptions don't get lost in code
On Mon, 2014-01-20 at 22:51 +0100, Peter Zijlstra wrote:
I'm still waiting for someone to explain what's wrong with:
static inline void mwait_idle(void)
{
local_irq_enable();
mwait_idle_with_hints(0, 0);
}
How about just do that going forward, it work, and can always be fixed
On Sun, Jan 19, 2014 at 11:45:43PM -0500, Len Brown wrote:
+static void mwait_idle(void)
+{
+ mwait_idle_with_hints(0, 0);
+}
+
The reason the patch above will crash Core2 machines is because
core2 machines don't support mwait_idle_with_hints().
The calling sequence for old and
On Sun, Jan 19, 2014 at 08:00:19PM -0500, Len Brown wrote:
On Wed, Jan 15, 2014 at 10:58 PM, Stephen Rothwell s...@canb.auug.org.au
wrote:
Hi all,
After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
arch/x86/kernel/process.c: In function
On Mon, Jan 20, 2014 at 4:51 AM, Stephen Rothwell s...@canb.auug.org.au wrote:
On Sat, 18 Jan 2014 10:46:06 +0100 Mike Galbraith bitbuc...@online.de wrote:
I hope it doesn't look quite like that, next-20140117 is -ENOBOOT on
Q6600 box. See below for an alternative.
idle: kill unnecessary
On Mon, Jan 20, 2014 at 9:42 AM, Sedat Dilek sedat.di...@gmail.com wrote:
On Mon, Jan 20, 2014 at 4:51 AM, Stephen Rothwell s...@canb.auug.org.au
wrote:
On Sat, 18 Jan 2014 10:46:06 +0100 Mike Galbraith bitbuc...@online.de
wrote:
I hope it doesn't look quite like that, next-20140117 is
On 01/20/2014 12:26 AM, Peter Zijlstra wrote:
On Sun, Jan 19, 2014 at 11:45:43PM -0500, Len Brown wrote:
+static void mwait_idle(void)
+{
+ mwait_idle_with_hints(0, 0);
+}
+
The reason the patch above will crash Core2 machines is because
core2 machines don't support
On Mon, Jan 20, 2014 at 12:56:47AM -0800, H. Peter Anvin wrote:
On 01/20/2014 12:26 AM, Peter Zijlstra wrote:
On Sun, Jan 19, 2014 at 11:45:43PM -0500, Len Brown wrote:
+static void mwait_idle(void)
+{
+ mwait_idle_with_hints(0, 0);
+}
+
The reason the patch above will crash
On Mon, 2014-01-20 at 09:42 +0100, Sedat Dilek wrote:
On Mon, Jan 20, 2014 at 4:51 AM, Stephen Rothwell s...@canb.auug.org.au
wrote:
On Sat, 18 Jan 2014 10:46:06 +0100 Mike Galbraith bitbuc...@online.de
wrote:
I hope it doesn't look quite like that, next-20140117 is -ENOBOOT on
On 01/20/2014 01:16 AM, Peter Zijlstra wrote:
The difference is the STI!
So do the local_irq_enable(); mwait_idle_with_hints(0,0); thing.
No, that doesn't work. The point of __sti_mwait() is that the STI is
the instruction immediately before the MWAIT, just like the combination
STI;HLT.
On Mon, Jan 20, 2014 at 10:17 AM, Mike Galbraith bitbuc...@online.de wrote:
On Mon, 2014-01-20 at 09:42 +0100, Sedat Dilek wrote:
On Mon, Jan 20, 2014 at 4:51 AM, Stephen Rothwell s...@canb.auug.org.au
wrote:
On Sat, 18 Jan 2014 10:46:06 +0100 Mike Galbraith bitbuc...@online.de
wrote:
* H. Peter Anvin h...@zytor.com wrote:
On 01/20/2014 01:16 AM, Peter Zijlstra wrote:
The difference is the STI!
So do the local_irq_enable(); mwait_idle_with_hints(0,0); thing.
No, that doesn't work. The point of __sti_mwait() is that the STI
is the instruction immediately
On Mon, 2014-01-20 at 10:25 +0100, Sedat Dilek wrote:
It's about the handling of fixes for -next.
Ah, it was a gripe in query form. My bad.
-Mike
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info
On Mon, Jan 20, 2014 at 01:23:00AM -0800, H. Peter Anvin wrote:
On 01/20/2014 01:16 AM, Peter Zijlstra wrote:
The difference is the STI!
So do the local_irq_enable(); mwait_idle_with_hints(0,0); thing.
No, that doesn't work. The point of __sti_mwait() is that the STI is
the
On Mon, Jan 20, 2014 at 09:30:21AM +0100, Peter Zijlstra wrote:
Then make them so. The fact was that most of the mwait idle sites
were bloody broken. And the single mwait_idle_with_hints() function
presents a single nice function that does all the required magics.
To stress this a bit more;
On 01/20/2014 02:13 AM, Peter Zijlstra wrote:
On Mon, Jan 20, 2014 at 09:30:21AM +0100, Peter Zijlstra wrote:
Then make them so. The fact was that most of the mwait idle sites
were bloody broken. And the single mwait_idle_with_hints() function
presents a single nice function that does all the
On 01/20/2014 01:55 AM, Peter Zijlstra wrote:
Ok, so I still don't get the problem of enabling interrupts early.
If we enable them early we can get interrupts; which afaict fall into
two groups, those that do and do not set NEED_RESCHED.
For those that do not set NEED_RESCHED, we'd have
On Mon, Jan 20, 2014 at 03:00:29AM -0800, H. Peter Anvin wrote:
On 01/20/2014 01:55 AM, Peter Zijlstra wrote:
Ok, so I still don't get the problem of enabling interrupts early.
If we enable them early we can get interrupts; which afaict fall into
two groups, those that do and do not
On Mon, Jan 20, 2014 at 02:19:30AM -0800, H. Peter Anvin wrote:
On 01/20/2014 02:13 AM, Peter Zijlstra wrote:
On Mon, Jan 20, 2014 at 09:30:21AM +0100, Peter Zijlstra wrote:
Then make them so. The fact was that most of the mwait idle sites
were bloody broken. And the single
+static void mwait_idle(void)
+{
+ mwait_idle_with_hints(0, 0);
+}
+
The reason the patch above will crash Core2 machines is because
core2 machines don't support mwait_idle_with_hints().
The calling sequence for old and new MWAIT instructions is different.
The former must be invoked with
On Sat, 18 Jan 2014 10:46:06 +0100 Mike Galbraith wrote:
>
> I hope it doesn't look quite like that, next-20140117 is -ENOBOOT on
> Q6600 box. See below for an alternative.
>
> idle: kill unnecessary mwait_idle() resched IPIs
OK, so despite even further discussion, I have applied this as a
On 01/19/2014 05:00 PM, Len Brown wrote:
> On Wed, Jan 15, 2014 at 10:58 PM, Stephen Rothwell
> wrote:
>> Hi all,
>>
>> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
>> failed like this:
>>
>> arch/x86/kernel/process.c: In function 'mwait_idle':
>>
On Wed, Jan 15, 2014 at 10:58 PM, Stephen Rothwell
wrote:
> Hi all,
>
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> arch/x86/kernel/process.c: In function 'mwait_idle':
> /scratch/sfr/next/arch/x86/kernel/process.c:434:3: error: implicit
>
On Wed, Jan 15, 2014 at 10:58 PM, Stephen Rothwell s...@canb.auug.org.au
wrote:
Hi all,
After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
arch/x86/kernel/process.c: In function 'mwait_idle':
/scratch/sfr/next/arch/x86/kernel/process.c:434:3:
On 01/19/2014 05:00 PM, Len Brown wrote:
On Wed, Jan 15, 2014 at 10:58 PM, Stephen Rothwell s...@canb.auug.org.au
wrote:
Hi all,
After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
arch/x86/kernel/process.c: In function 'mwait_idle':
On Sat, 18 Jan 2014 10:46:06 +0100 Mike Galbraith bitbuc...@online.de wrote:
I hope it doesn't look quite like that, next-20140117 is -ENOBOOT on
Q6600 box. See below for an alternative.
idle: kill unnecessary mwait_idle() resched IPIs
OK, so despite even further discussion, I have applied
+static void mwait_idle(void)
+{
+ mwait_idle_with_hints(0, 0);
+}
+
The reason the patch above will crash Core2 machines is because
core2 machines don't support mwait_idle_with_hints().
The calling sequence for old and new MWAIT instructions is different.
The former must be invoked with
On Sat, Jan 18, 2014 at 11:14:57AM -0800, H. Peter Anvin wrote:
> >> Could something like this work?
> >>
> >>local_irq_enable();
> >>mwait_idle_with_hints(0,0);
> >>
> This means an interrupt window is open and we can take an interrupt
> between checking need_resched and the MWAIT, which
On 01/18/2014 07:21 AM, Mike Galbraith wrote:
> On Sat, 2014-01-18 at 13:44 +0100, Peter Zijlstra wrote:
>> On Sat, Jan 18, 2014 at 10:46:06AM +0100, Mike Galbraith wrote:
>>>
>>> I hope it doesn't look quite like that, next-20140117 is -ENOBOOT on
>>> Q6600 box. See below for an alternative.
>>
On Sat, 2014-01-18 at 13:44 +0100, Peter Zijlstra wrote:
> On Sat, Jan 18, 2014 at 10:46:06AM +0100, Mike Galbraith wrote:
> >
> > I hope it doesn't look quite like that, next-20140117 is -ENOBOOT on
> > Q6600 box. See below for an alternative.
>
> Urgh, I see, we call the idle arch_cpu_idle()
2014-01-18, 13:44:51 +0100, Peter Zijlstra wrote:
> On Sat, Jan 18, 2014 at 10:46:06AM +0100, Mike Galbraith wrote:
> >
> > I hope it doesn't look quite like that, next-20140117 is -ENOBOOT on
> > Q6600 box. See below for an alternative.
>
> Urgh, I see, we call the idle arch_cpu_idle()
On Sat, Jan 18, 2014 at 10:46:06AM +0100, Mike Galbraith wrote:
>
> I hope it doesn't look quite like that, next-20140117 is -ENOBOOT on
> Q6600 box. See below for an alternative.
Urgh, I see, we call the idle arch_cpu_idle() callback with irqs
disabled.
Could something like this work?
On Fri, 2014-01-17 at 14:45 +1100, Stephen Rothwell wrote:
> Hi all,
>
> On Thu, 16 Jan 2014 14:51:08 -0800 "H. Peter Anvin" wrote:
> >
> > On 01/16/2014 02:34 PM, Stephen Rothwell wrote:
> > >
> > > On Thu, 16 Jan 2014 23:25:36 +0100 Peter Zijlstra
> > > wrote:
> > >>
> > >> On Fri, Jan 17,
On Fri, 2014-01-17 at 14:45 +1100, Stephen Rothwell wrote:
Hi all,
On Thu, 16 Jan 2014 14:51:08 -0800 H. Peter Anvin h...@zytor.com wrote:
On 01/16/2014 02:34 PM, Stephen Rothwell wrote:
On Thu, 16 Jan 2014 23:25:36 +0100 Peter Zijlstra
pet...@infradead.org wrote:
On Fri,
On Sat, Jan 18, 2014 at 10:46:06AM +0100, Mike Galbraith wrote:
I hope it doesn't look quite like that, next-20140117 is -ENOBOOT on
Q6600 box. See below for an alternative.
Urgh, I see, we call the idle arch_cpu_idle() callback with irqs
disabled.
Could something like this work?
2014-01-18, 13:44:51 +0100, Peter Zijlstra wrote:
On Sat, Jan 18, 2014 at 10:46:06AM +0100, Mike Galbraith wrote:
I hope it doesn't look quite like that, next-20140117 is -ENOBOOT on
Q6600 box. See below for an alternative.
Urgh, I see, we call the idle arch_cpu_idle() callback with
On Sat, 2014-01-18 at 13:44 +0100, Peter Zijlstra wrote:
On Sat, Jan 18, 2014 at 10:46:06AM +0100, Mike Galbraith wrote:
I hope it doesn't look quite like that, next-20140117 is -ENOBOOT on
Q6600 box. See below for an alternative.
Urgh, I see, we call the idle arch_cpu_idle() callback
On 01/18/2014 07:21 AM, Mike Galbraith wrote:
On Sat, 2014-01-18 at 13:44 +0100, Peter Zijlstra wrote:
On Sat, Jan 18, 2014 at 10:46:06AM +0100, Mike Galbraith wrote:
I hope it doesn't look quite like that, next-20140117 is -ENOBOOT on
Q6600 box. See below for an alternative.
Urgh, I see,
On Sat, Jan 18, 2014 at 11:14:57AM -0800, H. Peter Anvin wrote:
Could something like this work?
local_irq_enable();
mwait_idle_with_hints(0,0);
This means an interrupt window is open and we can take an interrupt
between checking need_resched and the MWAIT, which couldn't happen
Hi all,
On Thu, 16 Jan 2014 14:51:08 -0800 "H. Peter Anvin" wrote:
>
> On 01/16/2014 02:34 PM, Stephen Rothwell wrote:
> >
> > On Thu, 16 Jan 2014 23:25:36 +0100 Peter Zijlstra
> > wrote:
> >>
> >> On Fri, Jan 17, 2014 at 07:46:28AM +1100, Stephen Rothwell
> >> wrote:
> >>>
> >>> On Thu, 16
On Thursday, January 16, 2014 02:33:02 PM Mikulas Patocka wrote:
>
> On Thu, 16 Jan 2014, Peter Zijlstra wrote:
>
> > > > retry++;
> > > > __asm__ __volatile__(
> > > > @@ -217,6 +220,7 @@ static void speedstep_set_state(unsigned int state)
> > > >
> > > >
On 01/16/2014 02:34 PM, Stephen Rothwell wrote:
> Hi Peter,
>
> On Thu, 16 Jan 2014 23:25:36 +0100 Peter Zijlstra
> wrote:
>>
>> On Fri, Jan 17, 2014 at 07:46:28AM +1100, Stephen Rothwell
>> wrote:
>>>
>>> On Thu, 16 Jan 2014 13:19:55 +0100 Peter Zijlstra
>>> wrote:
I think the
Hi Peter,
On Thu, 16 Jan 2014 23:25:36 +0100 Peter Zijlstra wrote:
>
> On Fri, Jan 17, 2014 at 07:46:28AM +1100, Stephen Rothwell wrote:
> >
> > On Thu, 16 Jan 2014 13:19:55 +0100 Peter Zijlstra
> > wrote:
> > >
> > > I think the below ought to work
> >
> > To be clear, all you did was
On Fri, Jan 17, 2014 at 07:46:28AM +1100, Stephen Rothwell wrote:
> Hi Peter,
>
> On Thu, 16 Jan 2014 13:19:55 +0100 Peter Zijlstra
> wrote:
> >
> > I think the below ought to work
>
> To be clear, all you did was replace the body of mwait_idle() with
>
> mwait_idle_with_hints(0, 0);
On 01/16/2014 04:19 AM, Peter Zijlstra wrote:
> + * MONITOR/MWAIT with no hints, used for default default C1 state.
The default default?
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo
Hi Peter,
On Thu, 16 Jan 2014 13:19:55 +0100 Peter Zijlstra wrote:
>
> I think the below ought to work
To be clear, all you did was replace the body of mwait_idle() with
mwait_idle_with_hints(0, 0);
(and the comment above it)? I need to apply in incremental patch in the
merge commit.
On Thu, 16 Jan 2014, Peter Zijlstra wrote:
> > > retry++;
> > > __asm__ __volatile__(
> > > @@ -217,6 +220,7 @@ static void speedstep_set_state(unsigned int state)
> > >
> > > /* enable IRQs */
> > > local_irq_restore(flags);
> > > + preempt_enable();
> > >
> > >
On Thu, Jan 16, 2014 at 02:58:29PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> arch/x86/kernel/process.c: In function 'mwait_idle':
> /scratch/sfr/next/arch/x86/kernel/process.c:434:3: error:
On Tue, Jan 14, 2014 at 04:43:43PM -0500, Mikulas Patocka wrote:
> > @@ -200,7 +201,9 @@ static void speedstep_set_state(unsigned int state)
> > if (retry) {
> > pr_debug("retry %u, previous result %u, waiting...\n",
> > retry,
On Tue, Jan 14, 2014 at 04:43:43PM -0500, Mikulas Patocka wrote:
@@ -200,7 +201,9 @@ static void speedstep_set_state(unsigned int state)
if (retry) {
pr_debug(retry %u, previous result %u, waiting...\n,
retry, result);
+
On Thu, Jan 16, 2014 at 02:58:29PM +1100, Stephen Rothwell wrote:
Hi all,
After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
arch/x86/kernel/process.c: In function 'mwait_idle':
/scratch/sfr/next/arch/x86/kernel/process.c:434:3: error: implicit
301 - 400 of 454 matches
Mail list logo
