Messages in this thread | | | Date | Mon, 10 Jul 2006 02:28:52 -0700 | From | Stephane Eranian <> | Subject | Re: [patch] i386: use thread_info flags for debug regs and IO bitmaps |
| |
Linus,
On Sat, Jul 08, 2006 at 02:26:53PM -0700, Linus Torvalds wrote: > > From: Stephane Eranian <eranian@hpl.hp.com> > > > > 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 > > 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.
-- -Stephane - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |