From owner-freebsd-amd64@freebsd.org Sun Aug 13 17:44:33 2017 Return-Path: Delivered-To: freebsd-amd64@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 DF53EDCD87E for ; Sun, 13 Aug 2017 17:44:33 +0000 (UTC) (envelope-from aijazbaig1@gmail.com) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 99AC677E27 for ; Sun, 13 Aug 2017 17:44:33 +0000 (UTC) (envelope-from aijazbaig1@gmail.com) Received: by mail-vk0-x235.google.com with SMTP id j189so25999069vka.0 for ; Sun, 13 Aug 2017 10:44:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=0jdOxk6flnVzrT9hFDnLYD6N3PHk163Z+7kNeONu5X4=; b=YLhaj9zgIcK1/+8MDOYb8N/JFcez2y2brTYi2ZW2Ut3Gu+fV8KS8WYcE4SJrZjLAUC ZD0LZGDiNp0pZA2zKRe62bkwH8kqtQLc4jaHCZCl82pVYoppsed/N5YL0X2ScPtK/H18 qv2Zwx+sKzUvjqSHHwUyfw+Jgy4y4+xDDN4W/YW3bCwYbmctUxeRRfX2WeXR1BfmC19H fiYJ2gwzlj15WRKL5fciU3UFKIO1Vs7sSAyEmpW5Bo2Zbfbe2bQh9Hoir5szKNNfe31/ P+/jJ62ZACnKUxlNbICEXUnbmv/41gsi/ljOFk9yVZTex4LaiefbN7LopPT3018nVT4y V/YQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=0jdOxk6flnVzrT9hFDnLYD6N3PHk163Z+7kNeONu5X4=; b=q3b3ae2lLjwVBXmRvs+vPrmrA04ZLlpk1L+QYMuebM53E9QgfTiL47XqWIkc8TrZ6B +6eGgGBp4CS3J0+UkCbNLGG63fHnZl1+X3oFTEV0UpxrouIiHPiEAJryEQike6GtSBpJ iBeIeMXkDFSbeKLnA0SEaymfcQgKuPz64z+ud/q9hHQRS12l/RnYG/RRWNnB7If84f1+ ZSCfDQn9/txb1miGIJMzbc6hDsHEO5wkMABuYPKEMrjqh2ID1T9CUO3BwQfZ/EKmgojH +7fDga4U/zJX9dS4qQ+jzZQ0ejZMfk/e/r82Yv9u6irOVEjkdJrOlOUntivrYq2m5U3r CiRw== X-Gm-Message-State: AHYfb5gz0yvqdszSNWdhAvRX4LDuNRP+3ciwUci0hYrlz9xRmHZUsPIY 5xLoYQuwOweI5/yGSYseg4DCM5QZQmx6 X-Received: by 10.31.53.136 with SMTP id c130mr12641979vka.205.1502646272502; Sun, 13 Aug 2017 10:44:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.55.198 with HTTP; Sun, 13 Aug 2017 10:44:32 -0700 (PDT) From: Aijaz Baig Date: Sun, 13 Aug 2017 23:14:32 +0530 Message-ID: Subject: buildworld fails on 10.3 amd64 To: freebsd-amd64@freebsd.org X-Mailman-Approved-At: Sun, 13 Aug 2017 20:03:07 +0000 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Aug 2017 17:44:34 -0000 I am trying to buildworld on 10.3 and I encounter an error: --- _worldtmp --- -------------------------------------------------------------- >>> Rebuilding the temporary build tree -------------------------------------------------------------- rm -rf /mnt/ObjDir/usr/src/tmp rm -rf /mnt/ObjDir/usr/src/lib32 mkdir -p /mnt/ObjDir/usr/src/tmp/lib mkdir -p /mnt/ObjDir/usr/src/tmp/usr mkdir -p /mnt/ObjDir/usr/src/tmp/legacy/bin mkdir -p /mnt/ObjDir/usr/src/tmp/legacy/usr mtree -deU -f /usr/src/etc/mtree/BSD.usr.dist -p /mnt/ObjDir/usr/src/tmp/legacy/usr >/dev/null mtree -deU -f /usr/src/etc/mtree/BSD.groff.dist -p /mnt/ObjDir/usr/src/tmp/legacy/usr >/dev/null mtree -deU -f /usr/src/etc/mtree/BSD.usr.dist -p /mnt/ObjDir/usr/src/tmp/usr >/dev/null mtree -deU -f /usr/src/etc/mtree/BSD.include.dist -p /mnt/ObjDir/usr/src/tmp/usr/include >/dev/null ln -sf /usr/src/sys /mnt/ObjDir/usr/src/tmp --- _legacy --- -------------------------------------------------------------- >>> stage 1.1: legacy release compatibility shims -------------------------------------------------------------- cd /usr/src; MAKEOBJDIRPREFIX=/mnt/ObjDir/usr/src/tmp INSTALL="sh /usr/src/tools/install.sh" PATH=/mnt/ObjDir/usr/src/tmp/ legacy/usr/sbin:/mnt/ObjDir/usr/src/tmp/legacy/usr/bin:/ mnt/ObjDir/usr/src/tmp/legacy/usr/games:/mnt/ObjDir/usr/src/ tmp/legacy/bin:/sbin:/bin:/usr/sbin:/usr/bin WORLDTMP=/mnt/ObjDir/usr/src/tmp VERSION="FreeBSD 10.3-RELEASE amd64 1003000" MAKEFLAGS="-m /usr/src/tools/build/mk -j 4 -J 15,16 -m /usr/src/share/mk" COMPILER_TYPE=clang make -f Makefile.inc1 DESTDIR= BOOTSTRAPPING=1003000 SSP_CFLAGS= -DWITHOUT_HTML -DWITHOUT_INFO -DNO_LINT -DWITHOUT_MAN -DNO_PIC -DNO_PROFILE -DNO_SHARED _BOOTSTRAP_MAKEINFO=yes -DNO_CPU_CFLAGS -DNO_WARNS -DNO_CTF -DEARLY_BUILD -DNO_TESTS legacy --- legacy --- ===> tools/build (obj,includes,depend,all,install) --- obj --- /mnt/ObjDir/usr/src/tmp/usr/src/tools/build created for /usr/src/tools/build --- includes --- ; cd /usr/src/tools/build; make buildincludes; make installincludes --- .depend --- rm -f .depend mkdep -f .depend -a -I/mnt/ObjDir/usr/src/tmp/legacy/usr/include -std=gnu99 /usr/src/tools/build/../../contrib/libc-pwcache/pwcache.c /usr/src/tools/build/../../contrib/libc-pwcache/pwcache.c:82:10: fatal error: 'namespace.h' file not found #include "namespace.h" ^ 1 error generated. mkdep: compile failed *** [.depend] Error code 1 make[3]: stopped in /usr/src/tools/build 1 error make[3]: stopped in /usr/src/tools/build *** [legacy] Error code 2 make[2]: stopped in /usr/src 1 error make[2]: stopped in /usr/src *** [_legacy] Error code 2 make[1]: stopped in /usr/src 1 error make[1]: stopped in /usr/src *** [buildworld] Error code 2 make: stopped in /usr/src 1 error make: stopped in /usr/src What is this error? Am I missing certain header files? Keen to hear -- Best Regards, Aijaz Baig From owner-freebsd-amd64@freebsd.org Mon Aug 14 20:44:01 2017 Return-Path: Delivered-To: freebsd-amd64@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 C1CEBDE38B0 for ; Mon, 14 Aug 2017 20:44:01 +0000 (UTC) (envelope-from Anton.Rang@dell.com) Received: from esa2.dell-outbound.iphmx.com (esa2.dell-outbound.iphmx.com [68.232.149.220]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.dell-outbound.iphmx.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 915BF6E32C for ; Mon, 14 Aug 2017 20:44:00 +0000 (UTC) (envelope-from Anton.Rang@dell.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1502743441; x=1534279441; h=from:to:subject:date:message-id:mime-version; bh=HQnBO2WBoYtoYmitiG1NcetuKTQxiUezz51Ye8Vhn2A=; b=iGpCqcXvDqLAk1U93L9i+f3tQto0fmso3x4ZAabhUb+WTQW54h1unIZR FRtLrvDh3kyFu43ED9yChrla5CHgdyu+elNLkZ5edu+Y+/zZGmpU1WQt1 w44UV9Z92wwBHfwGWbDD1YOLUnUHlRK9Sz4hYtlRe13YzPJpp65feS6L1 Q=; Received: from esa3.dell-outbound2.iphmx.com ([68.232.154.63]) by esa2.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Aug 2017 15:42:52 -0500 From: "Rang, Anton" Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa3.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Aug 2017 02:34:03 +0600 Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd05.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v7EKgpCT019265 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 14 Aug 2017 16:42:51 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd05.lss.emc.com v7EKgpCT019265 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=rsa.com; s=jan2013; t=1502743371; bh=3q+WDDhLlNTt1S8l6vcdHb3IsSI=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=uEtZzpHwbJpN0VfptMMTwG9MfBO1bEOnVUo0/LX+rEBNpsTZxBH7WL2FF9R04YsMC gi9r9bZmiwUGQEC+RWnBx6QmceOjWIOuyh8ae8OdYJprR9MBPJeHHY8oDEQXZ7JLYG 4F4IIX7bzhe4aAyTBT1p1HxW8KJ64taNfkyePDg4= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd05.lss.emc.com v7EKgpCT019265 Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd06.lss.emc.com (RSA Interceptor) for ; Mon, 14 Aug 2017 16:42:07 -0400 Received: from MXHUB212.corp.emc.com (MXHUB212.corp.emc.com [10.253.68.82]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v7EKgbgR019551 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL) for ; Mon, 14 Aug 2017 16:42:37 -0400 Received: from MX103CL02.corp.emc.com ([169.254.6.172]) by MXHUB212.corp.emc.com ([10.253.68.82]) with mapi id 14.03.0352.000; Mon, 14 Aug 2017 16:42:37 -0400 To: "freebsd-amd64@freebsd.org" Subject: XSAVE vs. XSAVEOPT in fpusave / fpu_kern_enter? Thread-Topic: XSAVE vs. XSAVEOPT in fpusave / fpu_kern_enter? Thread-Index: AdMVO36PuBDuT0bBRfW+7Y3UAgl9gQ== Date: Mon, 14 Aug 2017 20:42:35 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.13.46.145] MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com X-RSA-Classifications: public X-Mailman-Approved-At: Mon, 14 Aug 2017 23:34:45 +0000 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 20:44:01 -0000 Hi, While glancing at fpu_kern_enter, I noticed that fpusave() uses the XSAVE i= nstruction, but not XSAVEOPT. The instance in cpu_switch.S is patched if XS= AVEOPT is available, but should we also be able to use XSAVEOPT in fpusave = as well? I can't see any reason why not, but I'm not 100% sure that the sa= ve area is set up properly in all cases. Anton From owner-freebsd-amd64@freebsd.org Tue Aug 15 06:31:44 2017 Return-Path: Delivered-To: freebsd-amd64@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 0EF43DE5C38 for ; Tue, 15 Aug 2017 06:31:44 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail109.syd.optusnet.com.au (mail109.syd.optusnet.com.au [211.29.132.80]) by mx1.freebsd.org (Postfix) with ESMTP id CDD562DDD for ; Tue, 15 Aug 2017 06:31:43 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from [192.168.0.102] (c110-21-101-228.carlnfd1.nsw.optusnet.com.au [110.21.101.228]) by mail109.syd.optusnet.com.au (Postfix) with ESMTPS id 5AA9ED646BC; Tue, 15 Aug 2017 16:31:04 +1000 (AEST) Date: Tue, 15 Aug 2017 16:31:03 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: "Rang, Anton" cc: "freebsd-amd64@freebsd.org" Subject: Re: XSAVE vs. XSAVEOPT in fpusave / fpu_kern_enter? In-Reply-To: Message-ID: <20170815153457.F898@besplex.bde.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=Yb7N30Zf c=1 sm=1 tr=0 a=PalzARQSbocsUSjMRkwAPg==:117 a=PalzARQSbocsUSjMRkwAPg==:17 a=kj9zAlcOel0A:10 a=Axpjx6Mqo98pvSUj6-YA:9 a=MtvexjCta48XrdwP:21 a=3T3jv-qoMHGG4XTa:21 a=CjuIK1q_8ugA:10 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 06:31:44 -0000 On Mon, 14 Aug 2017, Rang, Anton wrote: > While glancing at fpu_kern_enter, I noticed that fpusave() uses the XSAVE instruction, but not XSAVEOPT. The instance in cpu_switch.S is patched if XSAVEOPT is available, but should we also be able to use XSAVEOPT in fpusave as well? I can't see any reason why not, but I'm not 100% sure that the save area is set up properly in all cases. i386 does it in both places, but is differently badly organized. On amd64: In cpu_switch.S, xsave is inline and patched, by there is still branch logic to choose between fxsave and [xsave | xsaveopt]. The branch is not very slow and the xsave* case needs 3 extra instructions which would have to be patched out to avoid the branch by patching fxsave. In fpu.c, the save function is misnamed fpusave(). It actually saves the FPU state and various extensions starting with YMM. It uses branch logic to choose between fxsave and xsave but is missing support for xsaveopt. On i386: All saving goes through npxsave() which is not misnamed and not missing xsaveopt. However, this is misorganized and misnamed internally. It does the branch for xsaveopt directly, but calls fpusave() for other cases. fpusave() is misnamed by copy bad bits from amd64. fpusave() actually saves the FPU state and various extensions starting with MMX. It uses branch logic with 1 more branch than on amd64 to choose between fnsave and fxsave. NPX is the i486 name for the non-separate plain 80x87 FPU. Apparently Intel didn't want to scare programmers by mentioning floating point, or was preparing for non-FPU extensions starting with MMX. npx was a worse name than fpu at first since it was too special. Now it is a better name because it is less general after reinterpreting the 'n' (numeric) in it as "any sort of number, not restricted to floating point". Bitmaps and encrypted bits aren't numbers for most people, but they are close enough (closer than large cardinal numbers...). xpx or kspx (kitchen sink processing extension) would be a better name. and64 renamed npx to fpu at about the same time as the number extensions started exploding. The density of pure FPU support in amd64/fpu.c started lower than in i386/isa/npx.c and is now closer to 0. Intel started misnaming earlier. First, ssx was bowdlerised to sse. The x was rotated in the register names for xmm, then rotated alphabetically for ymm. avx has the x back in the right place. Bruce From owner-freebsd-amd64@freebsd.org Tue Aug 15 10:44:53 2017 Return-Path: Delivered-To: freebsd-amd64@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 B5009DCB191 for ; Tue, 15 Aug 2017 10:44:53 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [176.36.249.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 42F0169D35 for ; Tue, 15 Aug 2017 10:44:52 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v7FAifto064883 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 15 Aug 2017 13:44:41 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v7FAifto064883 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v7FAifIY064882; Tue, 15 Aug 2017 13:44:41 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 15 Aug 2017 13:44:41 +0300 From: Konstantin Belousov To: "Rang, Anton" Cc: "freebsd-amd64@freebsd.org" Subject: Re: XSAVE vs. XSAVEOPT in fpusave / fpu_kern_enter? Message-ID: <20170815104441.GG1700@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 10:44:53 -0000 On Mon, Aug 14, 2017 at 08:42:35PM +0000, Rang, Anton wrote: > Hi, > > While glancing at fpu_kern_enter, I noticed that fpusave() uses the > XSAVE instruction, but not XSAVEOPT. The instance in cpu_switch.S is > patched if XSAVEOPT is available, but should we also be able to use > XSAVEOPT in fpusave as well? I can't see any reason why not, but I'm > not 100% sure that the save area is set up properly in all cases. Yes, XSAVEOPT should be safe there. I have a WIP changes (for a long time) which emulate ifuncs in kernel. Then fpusave() becomes a function call through a pointer indirection, and avoids conditional, which makes adding XSAVEOPT variant free. But I postponed committing this change, and may postpone even more. If our system linker/external toolchain support gain a new linker that support ifunc, then it might be better to use real ifunc. From owner-freebsd-amd64@freebsd.org Sat Aug 19 09:38:48 2017 Return-Path: Delivered-To: freebsd-amd64@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 DBCE8DDD8EE for ; Sat, 19 Aug 2017 09:38:48 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-183.reflexion.net [208.70.211.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8F5FA6D69F for ; Sat, 19 Aug 2017 09:38:47 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 10790 invoked from network); 19 Aug 2017 09:38:46 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 19 Aug 2017 09:38:46 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.2) with SMTP; Sat, 19 Aug 2017 05:38:46 -0400 (EDT) Received: (qmail 22680 invoked from network); 19 Aug 2017 09:38:46 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 19 Aug 2017 09:38:46 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id A7362EC8697; Sat, 19 Aug 2017 02:38:45 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Disabling kernel hw-thread migration/stealing policies allows Ryzen to build lang/ghc (finally!) Message-Id: <818D4BF7-481A-4031-8EEE-0971738268CC@dsl-only.net> Date: Sat, 19 Aug 2017 02:38:45 -0700 To: freebsd-hackers , freebsd-amd64@freebsd.org X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Aug 2017 09:38:49 -0000 [This test was suggesetd by Don Lewis's comment 73 for buugzilla 221029.] I finally got a Ryzen based build of lang/ghc : # pkg search ghc ghc-8.0.2_1 Compiler for the functional language Haskell This used as a kernel context with: sysctl kern.sched.balance=0 sysctl kern.sched.steal_idle=0 and a poudriere context of: PARALLEL_JOBS=1 ALLOW_MAKE_JOBS=no and ALLOW_MAKE_JOBS_PACKAGES not having a match for lang/ghc The Ryzen was not otherwise loaded with activity (beyond normal background stuff in a simple configuration). (This means that kern.sched.balance=1 might have worked as it had nothing to do. In fact I have that test running now.) By contrast for the kernel context: sysctl kern.sched.balance=1 sysctl kern.sched.steal_idle=1 the lang/ghc build fails quickly compared to the somewhat over 1.5 hours it took for a build to complete. The detailed build step for the failure tends to vary from build attempt to build attempt. But they tend to involve Bus Errors for the failures. My context here is actually FreeBSD running as a guest in a VirtualBox virtual machine --that is running under Windows 10 Pro . The Ryzen has all 16 threads enabled but Virtual Box is set to supply 8 "processors" to the virtual machine (in VirtualBox terminology). But Poudriere is set to avoid parallel builds. Also: Prior build attempts had already built packages for lang/ghc's prerequisites. So the experiments here are just for the lang/ghc related build activity. === Mark Millard markmi at dsl-only.net From owner-freebsd-amd64@freebsd.org Sat Aug 19 11:15:24 2017 Return-Path: Delivered-To: freebsd-amd64@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 E0CB3DE2CD1 for ; Sat, 19 Aug 2017 11:15:24 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-185.reflexion.net [208.70.211.185]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 957067077C for ; Sat, 19 Aug 2017 11:15:24 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 32065 invoked from network); 19 Aug 2017 11:15:23 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 19 Aug 2017 11:15:23 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.2) with SMTP; Sat, 19 Aug 2017 07:15:23 -0400 (EDT) Received: (qmail 16981 invoked from network); 19 Aug 2017 11:15:22 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 19 Aug 2017 11:15:22 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 167F7EC8877; Sat, 19 Aug 2017 04:15:22 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Disabling kernel hw-thread migration/stealing policies allows Ryzen to build lang/ghc (finally!) Date: Sat, 19 Aug 2017 04:15:21 -0700 References: <818D4BF7-481A-4031-8EEE-0971738268CC@dsl-only.net> To: freebsd-hackers , freebsd-amd64@freebsd.org In-Reply-To: <818D4BF7-481A-4031-8EEE-0971738268CC@dsl-only.net> Message-Id: <66044D90-E5C9-4855-B358-4083A82590CE@dsl-only.net> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Aug 2017 11:15:25 -0000 On 2017-Aug-19, at 2:38 AM, Mark Millard wrote: > [This test was suggesetd by Don Lewis's comment 73 > for buugzilla 221029.] > > I finally got a Ryzen based build of lang/ghc : > > # pkg search ghc > ghc-8.0.2_1 Compiler for the functional language Haskell > > This used as a kernel context with: > > sysctl kern.sched.balance=0 > sysctl kern.sched.steal_idle=0 > > and a poudriere context of: > > PARALLEL_JOBS=1 > ALLOW_MAKE_JOBS=no > > and ALLOW_MAKE_JOBS_PACKAGES not having a match > for lang/ghc > > The Ryzen was not otherwise loaded with activity > (beyond normal background stuff in a simple > configuration). > > (This means that kern.sched.balance=1 might > have worked as it had nothing to do. In fact > I have that test running now.) > > By contrast for the kernel context: > > sysctl kern.sched.balance=1 > sysctl kern.sched.steal_idle=1 > > the lang/ghc build fails quickly compared to > the somewhat over 1.5 hours it took for a > build to complete. > > The detailed build step for the failure tends to > vary from build attempt to build attempt. But they > tend to involve Bus Errors for the failures. > > > My context here is actually FreeBSD > running as a guest in a VirtualBox > virtual machine --that is running under > Windows 10 Pro . The Ryzen has all 16 > threads enabled but Virtual Box is set > to supply 8 "processors" to the virtual > machine (in VirtualBox terminology). > But Poudriere is set to avoid parallel > builds. > > Also: Prior build attempts had already > built packages for lang/ghc's > prerequisites. So the experiments here > are just for the lang/ghc related > build activity. sysctl kern.sched.balance=0 sysctl kern.sched.steal_idle=0 with: #PARALLEL_JOBS=1 ALLOW_MAKE_JOBS=yes and ALLOW_MAKE_JOBS_PACKAGES having a match for lang/ghc also makes it to completion for building lang/ghc . (Much of the time 8 hw-threads being busy.) Ryzen has problems with some aspect(s) of how FreeBSD migrates work between threads. May be some stronger form of barrier(s) or some such would sidestep the issue(s) but be less drastic than use of: sysctl kern.sched.balance=0 sysctl kern.sched.steal_idle=0 === Mark Millard markmi at dsl-only.net