i386: use thread_info flags for debug regs and IO bitmaps
PATCH 1/1 i386: use thread_info flags for debug regs and IO bitmaps
From: Stephane Eranian <[email protected]>
Use thread info flags to track use of debug registers and IO bitmaps.
- add TIF_DEBUG to track when debug registers are active
- add TIF_IO_BITMAP to track when I/O bitmap is used
- modify __switch_to() to use the new TIF flags
---
I didn't see this patch get merged anywhere. Can you merge it, Andrew? It's independent of the x86_64 version that Andi has merged in his tree.
arch/i386/kernel/ioport.c | 1 arch/i386/kernel/process.c | 50 +++++++++++++++++++++++------------------ arch/i386/kernel/ptrace.c | 5 +++- include/asm-i386/thread_info.h | 7 +++++ 4 files changed, 41 insertions(+), 22 deletions(-)
arch/i386/kernel/ioport.c +1 -0
@@ -79,6 +79,7 @@ asmlinkage long sys_ioperm(unsigned longmemset (bitmap,0xff ,IO_BITMAP_BYTES ); t->io_bitmap_ptr = bitmap; +set_thread_flag (TIF_IO_BITMAP ); }/*
arch/i386/kernel/process.c +29 -21
100 lines not on this page · raw message
arch/i386/kernel/ptrace.c +4 -1
@@ -468,8 +468,11 @@ long arch_ptrace(struct task_struct *chifor (i=0 ; i<4 ; i++)if ((0x5f54 >> ((data >> (16 +4 *i)) &0xf )) &1 ) goto out_tsk; +if (data) +set_tsk_thread_flag (child,TIF_DEBUG ); +else +clear_tsk_thread_flag (child,TIF_DEBUG ); } - addr -= (long ) &dummy->u_debugreg; addr = addr >>2 ; child->thread.debugreg[addr] = data;
include/asm-i386/thread_info.h +7 -0
@@ -140,6 +140,8 @@ static inline struct thread_info *curren#define TIF_SECCOMP 8/* secure computing */ #define TIF_RESTORE_SIGMASK 9/* restore signal mask in do_signal() */ #define TIF_MEMDIE 16 +#define TIF_DEBUG 17/* uses debug registers */ +#define TIF_IO_BITMAP 18/* uses I/O bitmap */ #define _TIF_SYSCALL_TRACE (1<<TIF_SYSCALL_TRACE)#define _TIF_NOTIFY_RESUME (1<<TIF_NOTIFY_RESUME)
@@ -151,6 +153,8 @@ static inline struct thread_info *curren#define _TIF_SYSCALL_AUDIT (1<<TIF_SYSCALL_AUDIT)#define _TIF_SECCOMP (1<<TIF_SECCOMP)#define _TIF_RESTORE_SIGMASK (1<<TIF_RESTORE_SIGMASK) +#define _TIF_DEBUG (1<<TIF_DEBUG) +#define _TIF_IO_BITMAP (1<<TIF_IO_BITMAP)/* work to do on interrupt/exception return */ #define _TIF_WORK_MASK \
@@ -159,6 +163,9 @@ static inline struct thread_info *curren/* work to do on any return to u-space */ #define _TIF_ALLWORK_MASK (0x0000FFFF & ~_TIF_SECCOMP) +/* flags to check in __switch_to() */ +#define _TIF_WORK_CTXSW (_TIF_DEBUG|_TIF_IO_BITMAP) +/* * Thread-synchronous status. *
Signature · 2 lines
Chuck "You can't read a newspaper if you can't read." --George W. Bush
arch/i386/kernel/process.c int dump_task_regs(struct task_struct *t · line 539
Quoted 5 lines · Chuck Ebbert
arch/i386/kernel/process.c +2
-2-static inline void -handle_io_bitmap (struct thread_struct *next,struct tss_struct *tss) +static inline void __switch_to_xtra (struct task_struct *next_p, +struct tss_struct *tss)
I would make that noinline
Rest looks good
-Andi
Review
Quoted 8 lines · Chuck Ebbert
From: Stephane Eranian <[email protected]>
Use thread info flags to track use of debug registers and IO bitmaps.
- add
TIF_DEBUGto track when debug registers are active(quoted diff) +0
-0- add TIF_IO_BITMAP to track when I/O bitmap is used - modify __switch_to() to use the new TIF flags
Can you explain what the advantages of this are?
I don't see it. It's just creating new state to describe state that we already had, and as far as I can tell, it's just a way to potentially have more new bugs thanks to the new state getting out of sync with the old one?
Linus
Quoted 11 lines · Linus Torvalds
Review
Quoted 8 lines · Chuck Ebbert
From: Stephane Eranian <[email protected]>
Use thread info flags to track use of debug registers and IO bitmaps.
- add
TIF_DEBUGto track when debug registers are active(quoted diff) +0
-0- add TIF_IO_BITMAP to track when I/O bitmap is used - modify __switch_to() to use the new TIF flags
Quoted 6 lines
Can you explain what the advantages of this are?
I don't see it. It's just creating new state to describe state that we already had, and as far as I can tell, it's just a way to potentially have more new bugs thanks to the new state getting out of sync with the old one?
It turns two checks in context switch into a single one. With some luck it will even touch one cache line less.
I requested this for x86-64 because Stephane wants to add more state to check (performance counters) in there for his perfmon2 patches, and with that infrastructure in place it can be added without adding more cost for the common case.
Chuck ported the x86-64 version to i386.
-Andi
Linus,
Quoted 8 lines · Linus Torvalds
Review
Quoted 7 lines
From: Stephane Eranian <[email protected]>
Use thread info flags to track use of debug registers and IO bitmaps.
- add
TIF_DEBUGto track when debug registers are active(quoted diff) +0
-0- add TIF_IO_BITMAP to track when I/O bitmap is used - modify __switch_to() to use the new TIF flags
Quoted 7 lines
Can you explain what the advantages of this are?
I don't see it. It's just creating new state to describe state that we already had, and as far as I can tell, it's just a way to potentially have more new bugs thanks to the new state getting out of sync with the old one?
AS Chuck explained, this is motivated by the perfmon patch. We need to save and restore the performance counters on context switch. We do it only for the tasks that use them. As such, this is yet another optional work that needs to be checked in __switch_to(). You have to test it for both the outgoing and incoming tasks. Andi suggested that instead of adding yet another test and touch yet another pair of cachelines, we pack all the 'extra' work into a single bitfield per task. This way the number of cachelines touched is limited to two for the debug registers, I/O bitmap and later perfmon. I leveraged the TIF mechanism for this as it seemed quite appropriate.
As you point out, it adds a little bit of complexity in that you need to ensure that when you touch the debug registers and/or the I/O bitmap, we keep the TIF flags in sync. The patch I submitted ensures that. The good thing is that, for both, the number of places were they are activated/stopped is very limited.
Signature · 1 line
-Stephane