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]
Message-ID: <20120614164926.GC333@phenom.dumpdata.com>
Date:	Thu, 14 Jun 2012 12:49:26 -0400
From:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To:	David Vrabel <david.vrabel@...rix.com>
Cc:	"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"x86@...nel.org" <x86@...nel.org>, "H. Peter Anvin" <hpa@...or.com>
Subject: Re: [PATCH] x86/xen: avoid updating TLS descriptors if they haven't
 changed

On Thu, Jun 14, 2012 at 03:52:19PM +0100, David Vrabel wrote:
> On 07/06/12 18:01, David Vrabel wrote:
> > From: David Vrabel <david.vrabel@...rix.com>
> > 
> > When switching tasks in a Xen PV guest, avoid updating the TLS
> > descriptors if they haven't changed.  This improves the speed of
> > context switches by almost 10% as much of the time the descriptors are
> > the same or only one is different.
> > 
> > The descriptors written into the GDT by Xen are modified from the
> > values passed in the update_descriptor hypercall so we keep shadow
> > copies of the three TLS descriptors to compare against.
> > 
> > lmbench3 test     Before  After  Improvement
> > --------------------------------------------
> > lat_ctx -s 32 24   7.19    6.52  9%
> > lat_pipe          12.56   11.66  7%
> > 
> > Signed-off-by: David Vrabel <david.vrabel@...rix.com>
> > ---
> > I note that the comment in asm/desc_defs.h says the 'a' and 'b' fields
> > in desc_struct as deprecated but there seems to be no suitable
> > alternatives.
> 
> ping?  Any opinion on this patch from the x86 side?  If it's okay can we
> get an ack so Konrad can take the patch via his tree.

It breaks my all my bootup tests - so NACK until at least that is fixed.
I think I sent you the whole serial log - is there something else that would help
narrow it down?
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ