Date: Fri, 13 May 2011 22:36:50 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: Attilio Rao <attilio@freebsd.org> Cc: src-committers@freebsd.org, Artem Belevich <art@freebsd.org>, Oleksandr Tymoshenko <gonzo@freebsd.org>, Bruce Evans <brde@optusnet.com.au>, svn-src-projects@freebsd.org, Warner Losh <imp@freebsd.org> Subject: Re: svn commit: r221614 - projects/largeSMP/sys/powerpc/include Message-ID: <20110513193650.GY48734@deviant.kiev.zoral.com.ua> In-Reply-To: <BANLkTin9RLbtLeWYGeQN1ksqPjOcnkoOfw@mail.gmail.com> References: <BANLkTinaWDcaiZiB3G5Szoaho1jVSeniMA@mail.gmail.com> <BANLkTimj3ohmvACmvcPa3yrdsUj=4D2V3Q@mail.gmail.com> <BANLkTikSgEXZz8vjj7kuyeWQE_oKqzB8ug@mail.gmail.com> <BANLkTinHGpL5tC3-5jOPUq6bJ2Ks7j_Dww@mail.gmail.com> <BANLkTi=DOD9p-YUMm33D5ZShTjS_Q1hEvg@mail.gmail.com> <BANLkTikj%2Bszgd%2BptzD6y%2BofPs%2B8bR7Z8ew@mail.gmail.com> <20110513221936.X1161@besplex.bde.org> <BANLkTinv9=iu8yzJD_ji4D6_txs173Kkxw@mail.gmail.com> <20110513154349.GV48734@deviant.kiev.zoral.com.ua> <BANLkTin9RLbtLeWYGeQN1ksqPjOcnkoOfw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--3uxt9koO+4Cm8N9x Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 13, 2011 at 05:45:52PM +0200, Attilio Rao wrote: > 2011/5/13 Kostik Belousov <kostikbel@gmail.com>: > > On Fri, May 13, 2011 at 03:50:47PM +0200, Attilio Rao wrote: > >> The per-cpu stuff also, is read only. The pm_active objects are > >> protected by VM locks. > > > > pm_active is not protected by any vm lock. It is set and cleared > > unlocked in the context switch code. But, the ctx switch only needs > > to set and clear a single bit at the time of switch, that makes > > the atomic operations sufficient for consistency. > > > > I had a WIP on the Intel PCID, were such protection was not enough, > > unfortunately. >=20 > You are indeed right, sorry. >=20 > What trouble were you having in your case, just for the sake of my > curiosity, if you can share? PCID is a feature where the cpu tag each TLB entry with some process ID (not Unix PID). When doing context switch, reload of %cr3 does not invalidate the TLB on the core, but instead rewrite the "current ID" value to use for tag fetch and store. For each pmap, when page entry is modified, we need to clear the TLB entry on all cores (threads) that could have the mapping in TLB. So each pmap grows additional cpu set which indicates such cores. In the microbenchmark, use of PCID gives two times speed increase of context switch. I do not remember exact details right now, but I did need a NAND operation on cpu sets with both operands potentially having more then one bit active. Currently the work is stalled, I lost access to the Westmere machine for testing. --3uxt9koO+4Cm8N9x Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk3NiFIACgkQC3+MBN1Mb4j5IgCgu4wBygxLffJPbfMIZMZntHBJ cywAn3nL5gYkbGlHV6KjN+xybAaHYJCW =ruJX -----END PGP SIGNATURE----- --3uxt9koO+4Cm8N9x--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110513193650.GY48734>