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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 5 Nov 2008 11:26:43 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	Alexander van Heukelum <heukelum@...tmail.fm>,
	Cyrill Gorcunov <gorcunov@...il.com>,
	Alexander van Heukelum <heukelum@...lshack.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>, lguest@...abs.org,
	jeremy@...source.com, Steven Rostedt <srostedt@...hat.com>,
	Mike Travis <travis@....com>
Subject: Re: [PATCH RFC/RFB] x86_64, i386: interrupt dispatch changes

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

> On Tue, Nov 04, 2008 at 09:44:00PM +0100, Ingo Molnar wrote:
> > 
> > * Alexander van Heukelum <heukelum@...tmail.fm> wrote:
> > 
> > > On Tue, 4 Nov 2008 18:05:01 +0100, "Andi Kleen" <andi@...stfloor.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/