From owner-freebsd-stable@freebsd.org Thu Nov 3 04:09:46 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 896C9C2CE23 for ; Thu, 3 Nov 2016 04:09:46 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (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 E6C8D1D8E for ; Thu, 3 Nov 2016 04:09:44 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id uA349WZl087611; Thu, 3 Nov 2016 15:09:33 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Thu, 3 Nov 2016 15:09:32 +1100 (EST) From: Ian Smith To: Konstantin Belousov cc: Jason Harmening , freebsd-stable@freebsd.org Subject: Re: huge nanosleep variance on 11-stable In-Reply-To: <20161102162808.GI54029@kib.kiev.ua> Message-ID: <20161103150114.M41537@sola.nimnet.asn.au> References: <6167392c-c37a-6e39-aa22-ca45435d6088@gmail.com> <20161102075509.GF54029@kib.kiev.ua> <3620f62e-0f4c-2d62-dcf8-e2fdff459250@gmail.com> <20161102162808.GI54029@kib.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 04:09:46 -0000 On Wed, 2 Nov 2016 18:28:08 +0200, Konstantin Belousov wrote: > On Wed, Nov 02, 2016 at 09:18:15AM -0700, Jason Harmening wrote: > > I think you are probably right. Hacking out the Intel-specific > > additions to C-state parsing in acpi_cpu_cx_cst() from r282678 (thus > > going back to sti;hlt instead of monitor+mwait at C1) fixed the problem > > for me. But r282678 also had the effect of enabling C2 and C3 on my > > system, because ACPI only presents MWAIT entries for those states and > > not p_lvlx. > You can do the same with "debug.acpi.disabled=mwait" loader tunable > without hacking the code. And set sysctl hw.acpi.cpu.cx_lowest to C1 to > enforce use of hlt instruction even when mwait states were requested. But hw.acpi.cpu.cx_lowest=C1 disables C2 & C3 etc, and Jason wanted those - but without using mwait - if I've read him right? cheers, Ian