From owner-freebsd-arch@FreeBSD.ORG Mon Aug 18 20:39:23 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3AF41CB1; Mon, 18 Aug 2014 20:39:23 +0000 (UTC) Received: from pp2.rice.edu (proofpoint2.mail.rice.edu [128.42.201.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F250E34A7; Mon, 18 Aug 2014 20:39:22 +0000 (UTC) Received: from pps.filterd (pp2.rice.edu [127.0.0.1]) by pp2.rice.edu (8.14.5/8.14.5) with SMTP id s7IKacaH028827; Mon, 18 Aug 2014 15:39:21 -0500 Received: from mh1.mail.rice.edu (mh1.mail.rice.edu [128.42.201.20]) by pp2.rice.edu with ESMTP id 1numser5te-1; Mon, 18 Aug 2014 15:39:21 -0500 X-Virus-Scanned: by amavis-2.7.0 at mh1.mail.rice.edu, auth channel Received: from 108-254-203-201.lightspeed.hstntx.sbcglobal.net (108-254-203-201.lightspeed.hstntx.sbcglobal.net [108.254.203.201]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh1.mail.rice.edu (Postfix) with ESMTPSA id AA3134601D5; Mon, 18 Aug 2014 15:39:20 -0500 (CDT) Message-ID: <53F26477.8050004@rice.edu> Date: Mon, 18 Aug 2014 15:39:20 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Peter Grehan , alc@freebsd.org, Konstantin Belousov Subject: Re: superpages for UMA References: <53F215A9.8010708@FreeBSD.org> <20140818183925.GP2737@kib.kiev.ua> <53F25E60.5050109@freebsd.org> In-Reply-To: <53F25E60.5050109@freebsd.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.629899992726084 urlsuspect_oldscore=0.0298999927260837 suspectscore=3 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=3.8904595378586e-08 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=498 rbsscore=0.629899992726084 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1408180228 Cc: arch@freebsd.org, Gleb Smirnoff , "Alexander V. Chernikov" , "Andrey V. Elsukov" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 20:39:23 -0000 On 08/18/2014 15:13, Peter Grehan wrote: >> Newer Intel CPUs have more entries, and AMD CPUs have long (since >> Barcelona) had more. In particular, they allow 2 MB page mappings to be >> cached in a larger L2 TLB. Nowadays, the trouble is with the 1 GB >> pages. >> A lot of CPUs still only support an 8 entry, 1 level TLB for 1 GB pages. > > There are new(ish) ones effectively without 1GB pages. From the > "Software Optimization Guide for AMD Family 16h Processors" > My recollection is that the first Intel processors to support 1 GB page mappings did this. They allowed you set PG_PS on the 1GB PTE, but there were no actual 1 GB page TLB entries. Also, after I modified the direct map on amd64 to use 1 GB pages, I noticed some strange performance anomalies. Specifically, sometimes performance was worse than I expected. It turned out that when the end of DRAM wasn't aligned to a 1 GB boundary, and the end of DRAM was mapped with a 1 GB PTE, the TLB would wind up with 4 KB mappings for anything covered by that last PTE. Whereas, before, it was at least 2 MB aligned and we would wind up with 2 MB page mappings in the TLB. So, now, the direct creation has an awareness of this issue. > "Smashing" > ... > "when the Family 16h processor encounters a 1-Gbyte page size, it will > smash translations of that 1-Gbyte region into 2-Mbyte TLB entries, each > of which translates a 2-Mbyte region of the 1-Gbyte page." > > later, > > Peter. >