[ANNOUNCE] 3.10.4-rt1

[ANNOUNCE] 3.10.4-rt1

[Thomas Gleixner]

Dear RT folks!

I'm pleased to announce the 3.10.4-rt1 patch set.

This is a mostly straight forward port of the 3.8 set. I had
experimented with a new implementation detail, but I did not get it
into a shape which would have made it applicable to RT.

Known issues:

      - SLAB support not working

      - Untested on ARM and PPC (hapless victims^W^Wtesters are
        welcome)

I'm about to leave for my annual kids summer camp kitchen duty, so I
let you fool around with the current pile.

Sebastian will help out while I'm away, so please send tons of patches
in the next couple of days and get this thing fixed before I
return. All I'm going to look for in my mail backlog is a mail with
the subject: 3.10.x-rty is perfect :)

The RT patch against 3.10.4 can be found here:

  http://www.kernel.org/pub/linux/kernel/projects/rt/3.8/patch-3.10.4-rt1.patch.xz

The split quilt queue is available at:

  http://www.kernel.org/pub/linux/kernel/projects/rt/3.8/patches-3.10.4-rt1.tar.xz

Enjoy,

        tglx

Re: [ANNOUNCE] 3.10.4-rt1

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 1412 bytes --]

Hi,

On Thu, Aug 01, 2013 at 01:24:10PM +0200, Thomas Gleixner wrote:
> Dear RT folks!
> 
> I'm pleased to announce the 3.10.4-rt1 patch set.
> 
> This is a mostly straight forward port of the 3.8 set. I had
> experimented with a new implementation detail, but I did not get it
> into a shape which would have made it applicable to RT.
> 
> Known issues:
> 
>       - SLAB support not working
> 
>       - Untested on ARM and PPC (hapless victims^W^Wtesters are
>         welcome)
> 
> I'm about to leave for my annual kids summer camp kitchen duty, so I
> let you fool around with the current pile.
> 
> Sebastian will help out while I'm away, so please send tons of patches
> in the next couple of days and get this thing fixed before I
> return. All I'm going to look for in my mail backlog is a mail with
> the subject: 3.10.x-rty is perfect :)
> 
> The RT patch against 3.10.4 can be found here:
> 
>   http://www.kernel.org/pub/linux/kernel/projects/rt/3.8/patch-3.10.4-rt1.patch.xz

Here's correct link:

https://www.kernel.org/pub/linux/kernel/projects/rt/3.10/patch-3.10.4-rt1.patch.xz

> The split quilt queue is available at:
> 
>   http://www.kernel.org/pub/linux/kernel/projects/rt/3.8/patches-3.10.4-rt1.tar.xz

and here:

https://www.kernel.org/pub/linux/kernel/projects/rt/3.10/patches-3.10.4-rt1.tar.xz

have fun on your kitchen duty ;-)

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [ANNOUNCE] 3.10.4-rt1

[Paul Gortmaker]

On Thu, Aug 1, 2013 at 7:24 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
> Dear RT folks!
>
> I'm pleased to announce the 3.10.4-rt1 patch set.
>
> This is a mostly straight forward port of the 3.8 set. I had
> experimented with a new implementation detail, but I did not get it
> into a shape which would have made it applicable to RT.
>
> Known issues:
>
>       - SLAB support not working
>
>       - Untested on ARM and PPC (hapless victims^W^Wtesters are
>         welcome)

We break at compile on powerpc with the below.  It happens because
in earlier RT,  we had TIF_NEED_RESCHED_LAZY as bit 14.  But
now, in 3.10 it is 18, and in breaking the 16 barrier, we get this:

arch/powerpc/kernel/entry_32.S: Assembler messages:
arch/powerpc/kernel/entry_32.S:367: Error: operand out of range
(0x000000000004ff87 is not between 0x0000000000000000 and
0x000000000000ffff)
arch/powerpc/kernel/entry_32.S:833: Error: operand out of range
(0x0000000000046006 is not between 0x0000000000000000 and
0x000000000000ffff)
arch/powerpc/kernel/entry_32.S:898: Error: operand out of range
(0x0000000000040000 is not between 0x0000000000000000 and
0x000000000000ffff)
arch/powerpc/kernel/entry_32.S:914: Error: operand out of range
(0x0000000000040004 is not between 0x0000000000000000 and
0x000000000000ffff)
arch/powerpc/kernel/entry_32.S:1236: Error: operand out of range
(0x0000000000040004 is not between 0x0000000000000000 and
0x000000000000ffff)
arch/powerpc/kernel/entry_32.S:1257: Error: operand out of range
(0x0000000000040004 is not between 0x0000000000000000 and
0x000000000000ffff)
arch/powerpc/kernel/entry_32.S:1259: Error: operand out of range
(0x0000000000046006 is not between 0x0000000000000000 and
0x000000000000ffff)
make[1]: *** [arch/powerpc/kernel/entry_32.o] Error 1

I've added Ben to the CC in case he has a suggestion on
how best to fix this, even though it is not yet mainline.

Paul.
--

>
> I'm about to leave for my annual kids summer camp kitchen duty, so I
> let you fool around with the current pile.
>
> Sebastian will help out while I'm away, so please send tons of patches
> in the next couple of days and get this thing fixed before I
> return. All I'm going to look for in my mail backlog is a mail with
> the subject: 3.10.x-rty is perfect :)
>
> The RT patch against 3.10.4 can be found here:
>
>   http://www.kernel.org/pub/linux/kernel/projects/rt/3.8/patch-3.10.4-rt1.patch.xz
>
> The split quilt queue is available at:
>
>   http://www.kernel.org/pub/linux/kernel/projects/rt/3.8/patches-3.10.4-rt1.tar.xz
>
> Enjoy,
>
>         tglx
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ANNOUNCE] 3.10.4-rt1

[Benjamin Herrenschmidt]

On Thu, 2013-08-01 at 20:03 -0400, Paul Gortmaker wrote:
> I've added Ben to the CC in case he has a suggestion on
> how best to fix this, even though it is not yet mainline.

Can you exchange with a TIF_ that isn't used in asm ? For example
TIF_PERFMON_* ? Keep all the asm ones below 16 and move up the ones
that are used in C only ?

Cheers,
Ben.

Re: [ANNOUNCE] 3.10.4-rt1

[Sebastian Andrzej Siewior]

On 08/02/2013 07:05 AM, Benjamin Herrenschmidt wrote:
> On Thu, 2013-08-01 at 20:03 -0400, Paul Gortmaker wrote:
>> I've added Ben to the CC in case he has a suggestion on
>> how best to fix this, even though it is not yet mainline.
> 
> Can you exchange with a TIF_ that isn't used in asm ? For example
> TIF_PERFMON_* ? Keep all the asm ones below 16 and move up the ones
> that are used in C only ?

I going to look later at this. I think I swapped one of the TIF_
defines in v3.8 so it should work.

> 
> Cheers,
> Ben.
> 

Sebastian

Re: [ANNOUNCE] 3.10.4-rt1

[Paul Gortmaker]

[Re: [ANNOUNCE] 3.10.4-rt1] On 02/08/2013 (Fri 14:45) Sebastian Andrzej Siewior wrote:

> On 08/02/2013 07:05 AM, Benjamin Herrenschmidt wrote:
> > On Thu, 2013-08-01 at 20:03 -0400, Paul Gortmaker wrote:
> >> I've added Ben to the CC in case he has a suggestion on
> >> how best to fix this, even though it is not yet mainline.
> > 
> > Can you exchange with a TIF_ that isn't used in asm ? For example
> > TIF_PERFMON_* ? Keep all the asm ones below 16 and move up the ones
> > that are used in C only ?
> 
> I going to look later at this. I think I swapped one of the TIF_
> defines in v3.8 so it should work.

Yep, 3.8 shuffled TIF_MEMDIE to the end of the queue, but
in 3.10, mainline commit 22ecbe8dcef has already done that trick.

The list of donor victims that aren't used in asm is getting
smaller, but TIF_POLLING_NRFLAG seems OK and it puts RESCHED
and RESCHED_LAZY right beside each other.

Thanks guys,
Paul.
--

diff --git a/arch/powerpc/include/asm/thread_info.h b/arch/powerpc/include/asm/thread_info.h
index 2469444..f50711f 100644
--- a/arch/powerpc/include/asm/thread_info.h
+++ b/arch/powerpc/include/asm/thread_info.h
@@ -92,8 +92,7 @@ static inline struct thread_info *current_thread_info(void)
 #define TIF_SYSCALL_TRACE	0	/* syscall trace active */
 #define TIF_SIGPENDING		1	/* signal pending */
 #define TIF_NEED_RESCHED	2	/* rescheduling necessary */
-#define TIF_POLLING_NRFLAG	3	/* true if poll_idle() is polling
-					   TIF_NEED_RESCHED */
+#define TIF_NEED_RESCHED_LAZY	3	/* lazy rescheduling necessary */
 #define TIF_32BIT		4	/* 32 bit binary */
 #define TIF_PERFMON_WORK	5	/* work for pfm_handle_work() */
 #define TIF_PERFMON_CTXSW	6	/* perfmon needs ctxsw calls */
@@ -109,7 +108,8 @@ static inline struct thread_info *current_thread_info(void)
 #define TIF_EMULATE_STACK_STORE	16	/* Is an instruction emulation
 						for stack store? */
 #define TIF_MEMDIE		17	/* is terminating due to OOM killer */
-#define TIF_NEED_RESCHED_LAZY	18	/* lazy rescheduling necessary */
+#define TIF_POLLING_NRFLAG	18	/* true if poll_idle() is polling
+					   TIF_NEED_RESCHED */
 
 /* as above, but as bit values */
 #define _TIF_SYSCALL_TRACE	(1<<TIF_SYSCALL_TRACE)

Re: [ANNOUNCE] 3.10.4-rt1

[Benjamin Herrenschmidt]

On Fri, 2013-08-02 at 10:19 -0400, Paul Gortmaker wrote:
> 
> Yep, 3.8 shuffled TIF_MEMDIE to the end of the queue, but
> in 3.10, mainline commit 22ecbe8dcef has already done that trick.
> 
> The list of donor victims that aren't used in asm is getting
> smaller, but TIF_POLLING_NRFLAG seems OK and it puts RESCHED
> and RESCHED_LAZY right beside each other.

Worst case we can turn it into a 32-bit and but I'd rather avoid it
as long as we can :-)

Cheers,
Ben.

Re: [ANNOUNCE] 3.10.4-rt1

[Sebastian Andrzej Siewior]

* Paul Gortmaker | 2013-08-02 10:19:36 [-0400]:

>The list of donor victims that aren't used in asm is getting
>smaller, but TIF_POLLING_NRFLAG seems OK and it puts RESCHED
>and RESCHED_LAZY right beside each other.

Applied & merged into the original patch. Thanks.

>Thanks guys,
>Paul.

Sebastian