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] [day] [month] [year] [list]
Message-Id: <4BD83C74020000780003C66C@vpn.id2.novell.com>
Date:	Wed, 28 Apr 2010 12:47:32 +0100
From:	"Jan Beulich" <JBeulich@...ell.com>
To:	"Eric Anholt" <eric@...olt.net>
Cc:	<linux-kernel@...r.kernel.org>
Subject: Re: intel_i830_chipset_flush(): local clflush() vs. global
	 wbinvd()

>>> Eric Anholt <eric@...olt.net> 28.04.10 01:00 >>>
>On Mon, 26 Apr 2010 10:26:52 +0100, "Jan Beulich" <JBeulich@...ell.com> wrote:
>> Eric, Brice,
>> 
>> what is the point of issuing wbinvd() on all CPUs here if clflush isn't
>> available, but using clflush() (if available) only on the current CPU?
>
>My reading of these two is that wbinvd affects this processor's cache
>lines, while clflush affects the cacheline regardless of which CPU owns
>it since they all share the same coherence domain.

Indeed, one can read it that way, although it seems unlikely to me that
it really means it (namely in large configurations the need to behave
that way may make clflush less preferable over wbinvd in some
situations). I'm trying to clarify this with Intel.

>Given that on many systems without CLFLUSH (8xx chipsets), we have
>issues with getting coherence to external memory successfully (note how
>neither of those instructions provide that!), I'm not sure it's a good
>time to be worrying about how to improve cache flushing performance on them!

No, the purpose of the question was not to hint at elimination of
the global wbinvd (which nevertheless could be reduced in scope),
but rather to find out why the same isn't needed on the clflush
path.

Jan

--
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