From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 15:28:37 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4FC5B1065670 for ; Tue, 31 Jan 2012 15:28:37 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id D01C98FC16 for ; Tue, 31 Jan 2012 15:28:36 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q0VFSTkc065474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 Jan 2012 17:28:29 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q0VFSS0M048382; Tue, 31 Jan 2012 17:28:28 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q0VFSSom048381; Tue, 31 Jan 2012 17:28:28 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 31 Jan 2012 17:28:28 +0200 From: Konstantin Belousov To: Paul Ambrose Message-ID: <20120131152828.GF3283@deviant.kiev.zoral.com.ua> References: <20120130063607.GV2726@deviant.kiev.zoral.com.ua> <20120130164316.GW2726@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ni93GHxFvA+th69W" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current Subject: Re: Does anyone try kib's Sandy Bridge PCID patch (pcid.2.patch)? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 15:28:37 -0000 --ni93GHxFvA+th69W Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Jan 31, 2012 at 09:23:50AM +0800, Paul Ambrose wrote: > ?? 2012??1??31?? ????12:43??Kostik Belousov ?????? > > On Mon, Jan 30, 2012 at 07:08:13PM +0800, Paul Ambrose wrote: > >> ?? 2012??1??30?? ????2:36??Kostik Belousov ?????? > >> > On Mon, Jan 30, 2012 at 10:15:51AM +0800, Paul Ambrose wrote: > >> >> I have two boxes, one is AMD Athlon 610e 2.4G with FreeBSD-current > >> >> patched with pcid.2.patch? It works well without other issue and it > >> >> seem the pcid patch > >> >> does not affect other part of the kernel. The other one is Sandy > >> > Athlons do not have PCID and probably will never implement it. They use > >> > other tricks to get similar optimizations, transparently to the OS. > >> > > >> Just curious, is this AMD similar optimizations > >> Address Space Number (ASN) and Global flag > >> US Patent 6,604,187. > >> http://www.chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html > > This and the same-important next item 'The TLB Flush Filter' is what > > I referred to. > > > >> I did not found anything about ASN in the AMD manual > > It is a transparent optimization, which does not require any OS support. > > Intel PCID is completely different, it shall be explicitely handled by OS. > > It is some consequence of the nested pages support, AFAIU. > > > >> > >> >> Bridge i5-2300 with FreeBSD 9 release patched with pcid.1.patch( the > >> >> pcid.2.patch seems > >> >> dependent on AVX and XSAVE stuffs which is available on -current). But > >> >> it hangs up just in a few minutes. I doubt the nvidia-driver which is > >> >> not recompiled with > >> >> patched kernel is the root, I will check this out later, but does > >> >> anyone meet similar problem? > >> > There are two many variations compared to the config I did tested. > >> > I do not see anything obvious in the changes between HEAD and stable/9 > >> > which could be blamed. Nvidia driver might be bigger suspect, but again, > >> > I am not aware of anything wrong with it. > >> > > >> >> > >> >> I have two question about the pcid.2.patch > >> > > >> > Item 2 is clean, I fixed it. > >> > > >> > For the item 1, I was only able to decipher the proposal to optimize > >> > the global shootdown handler to restore the %cr3 with bit 64 set to not > >> > invalidate current PCID. Is there some more changes ? > >> > > >> yes, that is what I meant. I was wondering using another way that each > >> process has different > >> pcid in each active processor, just as the freebsd mips and powerpc > >> uses. But obviously this way > >> is more friendly to non-pcid x86 processor. > > Each vmspace (or pmap) has unique PCID with the patch, at least until > > PCID space (12bit) is not exhausted. To really exhaust it, you need 4095 > > processes, so it is unlikely but possible event with the current settings. > > > Thank you for your explanation. I just disabled nvidia-driver( not > load it) , and > use "buildworld buildkernel" to test the pcid.1.patch with 9-release, > it seems the box reset before > completing the buildkernel, the attachment is my kernel config, would > you mind try it on > 9-release with pcid.1.patch? I will git 10-current a try to see if > there is something wrong with my hardware I just did checkout + buildworld + buildkernel with -j 10 on UFS with PCID turned on, everything finished fine. It is up to date HEAD. sandy% sysctl vm.stats.sys.v_swtch vm.pmap.pcid_save_cnt vm.stats.sys.v_swtch: 13743519 vm.pmap.pcid_save_cnt: 7853519 I.e. the TLB was not flushed one each second context switch. Trying the HEAD with the patch is probably easiest way forward. --ni93GHxFvA+th69W Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk8oCJwACgkQC3+MBN1Mb4i8YACfQce1x7zo1GpSYXkB/dPD3wgi XGUAoK8yATtEXCKSaLQZQA/FuFz3+0n8 =fmkn -----END PGP SIGNATURE----- --ni93GHxFvA+th69W--