From owner-cvs-src-old@FreeBSD.ORG Thu Jul 8 03:57:29 2010 Return-Path: Delivered-To: cvs-src-old@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10654106568A for ; Thu, 8 Jul 2010 03:57:29 +0000 (UTC) (envelope-from alc@FreeBSD.org) Received: from repoman.freebsd.org (repoman.freebsd.org [IPv6:2001:4f8:fff6::29]) by mx1.freebsd.org (Postfix) with ESMTP id F1EBC8FC15 for ; Thu, 8 Jul 2010 03:57:28 +0000 (UTC) Received: from repoman.freebsd.org (localhost [127.0.0.1]) by repoman.freebsd.org (8.14.3/8.14.3) with ESMTP id o683vSh6007383 for ; Thu, 8 Jul 2010 03:57:28 GMT (envelope-from alc@repoman.freebsd.org) Received: (from svn2cvs@localhost) by repoman.freebsd.org (8.14.3/8.14.3/Submit) id o683vSA4007382 for cvs-src-old@freebsd.org; Thu, 8 Jul 2010 03:57:28 GMT (envelope-from alc@repoman.freebsd.org) Message-Id: <201007080357.o683vSA4007382@repoman.freebsd.org> X-Authentication-Warning: repoman.freebsd.org: svn2cvs set sender to alc@repoman.freebsd.org using -f From: Alan Cox Date: Thu, 8 Jul 2010 03:35:00 +0000 (UTC) To: cvs-src-old@freebsd.org X-FreeBSD-CVS-Branch: HEAD Subject: cvs commit: src/sys/amd64/amd64 cpu_switch.S pmap.c X-BeenThere: cvs-src-old@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: **OBSOLETE** CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 03:57:29 -0000 alc 2010-07-08 03:35:00 UTC FreeBSD src repository Modified files: sys/amd64/amd64 cpu_switch.S pmap.c Log: SVN rev 209789 on 2010-07-08 03:35:00Z by alc Correctly maintain the per-cpu field "curpmap" on amd64 just like we do on i386. The consequences of not doing so on amd64 became apparent with the introduction of the COUNT_IPIS and COUNT_XINVLTLB_HITS options. Specifically, single-threaded applications were generating unnecessary IPIs to shoot-down the TLB on other processors. However, this is clearly nonsensical because a single-threaded application is only running on the current processor. The reason that this happens is that pmap_activate() is unable to properly update the old pmap's field "pm_active" without the correct "curpmap". So, in effect, stale bits in "pm_active" were leading pmap_protect(), pmap_remove(), pmap_remove_pages(), etc. to flush the TLB contents on some arbitrary processor that wasn't even running the same application. Reviewed by: kib MFC after: 3 weeks Revision Changes Path 1.171 +10 -12 src/sys/amd64/amd64/cpu_switch.S 1.706 +2 -0 src/sys/amd64/amd64/pmap.c