lkml.org 
[lkml]   [2008]   [Nov]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH RFC/RFB] x86_64, i386: interrupt dispatch changes

* Andi Kleen <andi@firstfloor.org> wrote:

> On Tue, Nov 04, 2008 at 09:44:00PM +0100, Ingo Molnar wrote:
> >
> > * Alexander van Heukelum <heukelum@fastmail.fm> wrote:
> >
> > > On Tue, 4 Nov 2008 18:05:01 +0100, "Andi Kleen" <andi@firstfloor.org>
> > > 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


\
 
 \ /
  Last update: 2008-11-05 11:29    [W:0.230 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site