Re: [PATCH RFC/RFB] x86_64, i386: interrupt dispatch changes

[Ingo Molnar]

* Andi Kleen <andi@xxxxxxxxxxxxxx> wrote:

> On Tue, Nov 04, 2008 at 09:44:00PM +0100, Ingo Molnar wrote:
> > 
> > * Alexander van Heukelum <heukelum@xxxxxxxxxxx> wrote:
> > 
> > > On Tue, 4 Nov 2008 18:05:01 +0100, "Andi Kleen" <andi@xxxxxxxxxxxxxx>
> > > said:
> > > > > not taking into account the cost of cs reading (which I
> > > > > don't suspect to be that expensive apart from writting,
> > > > 
> > > > GDT accesses have an implied LOCK prefix. Especially
> > > > on some older CPUs that could be slow.
> > > > 
> > > > I don't know if it's a problem or not but it would need
> > > > some careful benchmarking on different systems to make sure interrupt 
> > > > latencies are not impacted.
> > 
> > That's not a real issue on anything produced in this decade as we have 
> > had per CPU GDTs in Linux for about a decade as well.
> > 
> > It's only an issue on ancient CPUs that export all their LOCKed 
> > cycles to the bus. Pentium and older or so. The PPro got it right 
> > already.
> 
> ???  LOCK slowness is not because of the bus. And I know you know 
> that Ingo, so I don't know why you wrote that bogosity above.

.. of course the historic LOCK slowness was all due to the system bus: 
very old CPUs exported a LOCK signal to the system bus for every 
LOCK-prefix access (implicit and explicit) and that made it _really_ 
expensive. (hundreds of cycles)

... on reasonably modern CPUs the LOCK-ed access has been abstracted 
away to within the CPU, and the cost of LOCK-ed access is rather low 
(think 10-20 cycles - of course only if there's no cache miss cost) 
(That's obviously the case with the GDT, with is both per CPU and well 
cached.)

on _really_ modern CPUs LOCK can be as cheap as just a few cycles - so 
low that we can stop bothering about it in the future. There's no 
fundamental physical reason why the LOCK prefix (implicit or explicit) 
should be expensive.

the real reason why Alexander's patch needs to be measured is not the 
LOCK cycle of GDT accesses but what i pointed out in my first mail: 
the segmentation trick it plays. And that's why shrinking the stubs is 
probably a better idea which should be tried first.

... anyway, the unacceptable tone of your reply shows that you still 
have not changed a bit in your old habit of attacking and bullying 
people on lkml. All the other Intel engineers i'm working with as a 
maintainer show a very professional approach and are very easy to work 
with. You need to stop your attacks, and until you change this 
negative way of working with people i'll continue to ignore you.

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/