On Sat, Feb 09, 2008 at 10:40:37AM +0100, Ingo Molnar wrote:
quoted text
> 
> * Andi Kleen <andi@firstfloor.org> wrote:
> 
> > > because it's not just an open-coded __tlb_flush_all(), it _disables PGE 
> > > and keeps it so while the MTRR's are changed on all CPUs_.
> > 
> > Yes and? 
> 
> your first patch was outright wrong then you declared the second one a 
> "cleanup" while it changes behavior: bad in my book ;-)

I didn't claim that it didn't change the code -- you know
that I'm not a white space warrior, so I normally don't bother
with these kinds of patches -- just that it uses the usual Linux 
idioms for global TLB flushing.

quoted text
> > > Your patch adds __flush_tlb_all() which re-enables the PGE bit in cr4, 
> > > see asm-x86/tlbflush.h:
> > > 
> > >         /* clear PGE */
> > >         write_cr4(cr4 & ~X86_CR4_PGE);
> > >         /* write old PGE again and flush TLBs */
> > >         write_cr4(cr4);
> > > 
> > > so we'll keep PGE enabled during the MTRR setting - which changes 
> > > behavior.
> > 
> > It changes behaviour in some minor ways but I don't think it makes any 
> > difference. PGE only influences TLB flushes (according to its 
> > specification) and all the TLB flushes still run with PGE disabled.
> 
> now that i pointed out the difference, your position changed to "changes 
> behavior in minor ways" ;-)

The instruction stream changes (more cr* accesses), but the actual flushes 
do not.  There is the exact same number of global TLB flushes (three
as requested by the Intel manual); just instead of in weird open coded 
style they are done in standard Linux style. 

I think it's an improvement because the old code fooled me at least,
so it's not 100% obvious.

quoted text
> This is fragile code and almost nothing in the MTRR area is "minor", we 
> are just not touching this code unless it's really justified.

I don't think that's true actually; at least it doesn't match my experience
from maintaing that code for quite some time. MTRR was never particularly
fragile, just ugly.

Anyways I personally won't be fooled by that code again, so if 
you're not interested in (IMHO) cleaner and more readable and 
more maintaintable code then it's fine for me to not apply the patch.

-Andi

--
unsubscribe notice
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/