From owner-freebsd-amd64@freebsd.org Sun Mar 25 18:22:16 2018 Return-Path: Delivered-To: freebsd-amd64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 83716F609EF for ; Sun, 25 Mar 2018 18:22:16 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) Received: from sonic314-20.consmr.mail.gq1.yahoo.com (sonic314-20.consmr.mail.gq1.yahoo.com [98.137.69.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 11461727A9 for ; Sun, 25 Mar 2018 18:22:15 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) X-YMail-OSG: cgo82c8VM1lzG9I6Ziesmdtdg6LgIzBAmcsBuwyB.jlGra9BE31jEPEnwNkuoOv HqLXv_WIMSRjzHJD3y3rJESTzYIyh33wWrUUL6u248mV4yMogA180xavVtiGkadFWNS6EjcIzzm5 CH0aJX2h8ad2pQ7L7iixXQg5ti8h3oGKKPBA.MoylXAmg.ytGWGQyM1DomNlSGkZTtszp22qCcxG ADcjrTIul2tKJItwz6qRgXsIVNYT4yX0uFsC.9o3QLOFcVa7bUjnSO3HddALIVSxl6Z_jiLmRFhZ eBlv8Arvjn4dylrWl5v4kTlJci_9kxZcj4TdrFsZQjupms5l8GiRov7FBWfA6JepMZ_gOQSIRzYT 3qSH0qX5BWQXzwvulQO0XQKS9ByoFSWGpOsHrAX7WD41bIEevqAiHegTsGIiPXS2AltyxUKngEBy JQXxJkYyvdzufeVxXyN3vaEnVAqzutjW_ApsMQW.7CaZRCsM8mdqvBy2dxO8XQJ45QoGEhl57fQm FNnKSmwvnJQ.Clzq7_Ty70.eyKoGu1Pn3zQ-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Sun, 25 Mar 2018 18:22:09 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp426.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID d9a89e232fcac827685f8dd6e5b8e48b; Sun, 25 Mar 2018 17:41:39 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: head -r331499 amd64/threadripper panic in vm_page_free_prep during "poudriere bulk -a", after 14h 22m or so. Message-Id: <8D9C49CB-957E-40A5-8EB0-D90D8AC02060@yahoo.com> Date: Sun, 25 Mar 2018 10:41:38 -0700 To: FreeBSD Current , FreeBSD Hackers , freebsd-amd64@freebsd.org X-Mailer: Apple Mail (2.3445.5.20) X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.25 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, 25 Mar 2018 18:22:16 -0000 FreeBSD panic'd while attempting to see if a "poudriere bulk -w -a" would get the "unnecessary swapping" problem in my UFS-only context, -r331499 (non-debug but with symbols), under Hyper-V. This is a Ryzen Threadripper context, but I've no clue if that is important to the problem. This was after 14 hours or so of building: . . . [14:22:05] [18] [00:01:16] Finished devel/p5-Test-HTML-Tidy | = p5-Test-HTML-Tidy-1.00_1: Success [14:22:08] [18] [00:00:00] Building devel/ocaml-camlp5 | = ocaml-camlp5-6.16 So I've no clue if or how to repeat this. Unfortunately dump was unsuccessful. So all I have is the backtrace. Hand typed from a screen shot of the console window: cpuid =3D 18 time =3D 1521986594 KDB: stack backtrace: db_trace_self_srapper() at db_trace_self_srapper+0x2b/frame = 0xfffffe00f2e132a0 vpanic() at vpanic+0x18d/frame 0xfffffe00f2e13300 panic() at panic+0c43/frame 0xfffffe00f2e13360 vm_page_free_prep() at vm_page_free_prep+0x174/frame 0xfffffe00f2e13390 vm_page_free_toq() at vm_page_free_toq+0x11/frame 0xfffffe00f2e133b0 unlock_and_deallocate() at unlock_and_deallocate+0xbb/frame = 0xfffffe00f2e133d0 vm_fault_hold() at vm_fault_hold+0x1d04/frame 0xfffffe00f2e13500 proc_rwmem() at proc_rwmem+0x8d/frame 0xfffffe00f2e13570 proc_readmem() at proc_readmem+0x46/frame 0xfffffe00f2e135d0 get_proc_vector() at get_proc_vector+0x16e/frame 0xfffffe00f2e13660 proc_getauxv() at proc_getauxv+0x26/frame 0xfffffe00f2e136a0 elf64_note_procstat_auxv() at elf64_note_procstat_auxv+0x1ee/frame = 0xfffffe00f2e136f0 elf64_coredump() at elf64coredump+0x57c7/frame 0xfffffe00f2e137c0 sigexit() at sigexit+0x76f/frame 0xfffffe00f2e139b0 postsig() at postsig+0x289/frame 0xfffffe00f2e13a70 ast() at ast+0x357/frame 0xfffffe00f2e13ab0 doreti_ast() at doreti_ast+0x1f/frame 0x706d6f6320432041 KBD: enter: panic [ thread pid 61836 tid 101063 ] Stopped at kdb_enter+0x3b: movq $0,kdb_why The Hyper-V/Ryzen-Threadripper context was/is: FreeBSD 12.0-CURRENT r331499M amd64 FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based on = LLVM 6.0.0) SRAT: Ignoring memory at addr 0x1b28200000 VT(vga): text 80x25 Hyper-V Version: 10.0.16299 [SP0] = Features=3D0x2e7f PM Features=3D0x0 [C2] Features3=3D0xbed7b2 Timecounter "Hyper-V" frequency 10000000 Hz quality 2000 CPU: AMD Ryzen Threadripper 1950X 16-Core Processor (3393.73-MHz = K8-class CPU) Origin=3D"AuthenticAMD" Id=3D0x800f11 Family=3D0x17 Model=3D0x1 = Stepping=3D1 = Features=3D0x1783fbff = Features2=3D0xfed83203 AMD Features=3D0x2e500800 AMD Features2=3D0x3f3 Structured Extended = Features=3D0x201c01a9 XSAVE Features=3D0xf AMD Extended Feature Extensions ID EBX=3D0x4 Hypervisor: Origin =3D "Microsoft Hv" real memory =3D 115964116992 (110592 MB) avail memory =3D 112847249408 (107619 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 29 CPUs FreeBSD/SMP: 1 package(s) x 29 core(s) (I leave 3 hardware threads and some of the 128 GiBytes of memory for Windows 10 Pro x64.) FreeBSD and its swap are directly on NVMe SSDs, not in NTFS file(s). The M in -r331499M is for powerpc64/powerpc/arm64/armv7 related experiments, not amd64: # svnlite status /usr/src/ | sort ? /usr/src/nohup.out ? /usr/src/sys/amd64/conf/GENERIC-DBG ? /usr/src/sys/amd64/conf/GENERIC-NODBG ? /usr/src/sys/arm/conf/GENERIC-DBG ? /usr/src/sys/arm/conf/GENERIC-NODBG ? /usr/src/sys/arm64/conf/GENERIC-DBG ? /usr/src/sys/arm64/conf/GENERIC-NODBG ? /usr/src/sys/dts/arm/a83t.dtsi ? /usr/src/sys/dts/arm/sinovoip-bpi-m3.dts ? /usr/src/sys/dts/arm/sun8i-a83t-sinovoip-bpi-m3.dts ? /usr/src/sys/dts/arm/sun8i-a83t.dtsi ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-DBG ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG ? /usr/src/sys/powerpc/conf/GENERICvtsc-DBG ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODBG M /usr/src/contrib/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp M /usr/src/contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp M /usr/src/crypto/openssl/crypto/armcap.c M /usr/src/lib/libkvm/kvm_powerpc.c M /usr/src/lib/libkvm/kvm_private.c M /usr/src/stand/defs.mk M /usr/src/stand/powerpc/boot1.chrp/Makefile M /usr/src/stand/powerpc/kboot/Makefile M /usr/src/sys/arm64/arm64/identcpu.c M /usr/src/sys/conf/kmod.mk M /usr/src/sys/conf/ldscript.powerpc M /usr/src/sys/kern/subr_pcpu.c M /usr/src/sys/modules/dtb/allwinner/Makefile M /usr/src/sys/powerpc/aim/mmu_oea64.c M /usr/src/sys/powerpc/ofw/ofw_machdep.c M /usr/src/sys/powerpc/powerpc/interrupt.c M /usr/src/sys/powerpc/powerpc/mp_machdep.c M /usr/src/sys/powerpc/powerpc/trap.c M /usr/src/usr.bin/top/machine.c That last is because I've modified top to also report for swap: Maximum Observed Used (abbreviated: MaxObsUsed) when it is positive. For example: Swap: 256G Total, 483M Used, 483M MaxObsUsed, 256G Free =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-amd64@freebsd.org Sat Mar 31 10:29:13 2018 Return-Path: Delivered-To: freebsd-amd64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0E7F0F75D6D for ; Sat, 31 Mar 2018 10:29:13 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 9C04F7C905 for ; Sat, 31 Mar 2018 10:29:12 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 58BFCF75D68; Sat, 31 Mar 2018 10:29:12 +0000 (UTC) Delivered-To: amd64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 44885F75D66; Sat, 31 Mar 2018 10:29:12 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 AD5207C901; Sat, 31 Mar 2018 10:29:11 +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 w2VAT1aI061503 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 31 Mar 2018 13:29:04 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w2VAT1aI061503 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w2VAT1I3061502; Sat, 31 Mar 2018 13:29:01 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 31 Mar 2018 13:29:01 +0300 From: Konstantin Belousov To: current@freebsd.org Cc: amd64@freebsd.org, bde@freebsd.org Subject: i386 4/4 change Message-ID: <20180331102901.GN1774@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.9.4 (2018-02-28) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.25 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, 31 Mar 2018 10:29:13 -0000 Hi, the change to provide full 4G of address space for both kernel and user on i386 is ready to land. The motivation for the work was to both mitigate Meltdown on i386, and to give more breazing space for still used 32bit architecture. The patch was tested by Peter Holm, and I am satisfied with the code. If you use i386 with HEAD, I recommend you to apply the patch from https://reviews.freebsd.org/D14633 and report any regressions before the commit, not after. Unless a significant issue is reported, I plan to commit the change somewhere at Wed/Thu next week. Also I welcome patch comments and reviews. From owner-freebsd-amd64@freebsd.org Sat Mar 31 15:57:18 2018 Return-Path: Delivered-To: freebsd-amd64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B8DB7F6BB60 for ; Sat, 31 Mar 2018 15:57:18 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 564A169870 for ; Sat, 31 Mar 2018 15:57:18 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: by mailman.ysv.freebsd.org (Postfix) id 0F835F6BB5B; Sat, 31 Mar 2018 15:57:18 +0000 (UTC) Delivered-To: amd64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D84F0F6BB5A; Sat, 31 Mar 2018 15:57:17 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail110.syd.optusnet.com.au (mail110.syd.optusnet.com.au [211.29.132.97]) by mx1.freebsd.org (Postfix) with ESMTP id 2BCE26986D; Sat, 31 Mar 2018 15:57:16 +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 mail110.syd.optusnet.com.au (Postfix) with ESMTPS id 368CA107D6E; Sun, 1 Apr 2018 02:57:08 +1100 (AEDT) Date: Sun, 1 Apr 2018 02:57:07 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Konstantin Belousov cc: current@freebsd.org, amd64@freebsd.org, bde@freebsd.org Subject: Re: i386 4/4 change In-Reply-To: <20180331102901.GN1774@kib.kiev.ua> Message-ID: <20180401004833.L3296@besplex.bde.org> References: <20180331102901.GN1774@kib.kiev.ua> 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=cIaQihWN c=1 sm=1 tr=0 a=PalzARQSbocsUSjMRkwAPg==:117 a=PalzARQSbocsUSjMRkwAPg==:17 a=kj9zAlcOel0A:10 a=6I5d2MoRAAAA:8 a=DT3V0GftEuvEl1oZrMwA:9 a=1ZV-n0Uyi_mUE1wW:21 a=x2mBbHWrlB-c-CW1:21 a=-mbnTQFrRZPTw6fu:21 a=CjuIK1q_8ugA:10 a=IjZwj45LgO3ly-622nXo:22 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.25 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, 31 Mar 2018 15:57:19 -0000 On Sat, 31 Mar 2018, Konstantin Belousov wrote: > the change to provide full 4G of address space for both kernel and > user on i386 is ready to land. The motivation for the work was to both > mitigate Meltdown on i386, and to give more breazing space for still > used 32bit architecture. The patch was tested by Peter Holm, and I am > satisfied with the code. > > If you use i386 with HEAD, I recommend you to apply the patch from > https://reviews.freebsd.org/D14633 > and report any regressions before the commit, not after. Unless > a significant issue is reported, I plan to commit the change somewhere > at Wed/Thu next week. > > Also I welcome patch comments and reviews. It crashes at boot time in getmemsize() unless booted with loader which I don't want to use. It is much slower, and I couldn't find an option to turn it off. For makeworld, the system time is slightly more than doubled, the user time is increased by 16%, and the real time is increased by 21%. On amd64, turning off pti and not having ibrs gives almost no increase in makeworld times relative to old versions, and pti only costs about 5% IIRC. Makeworld is not very syscall-intensive. netblast is very syscall-intensive, and its throughput is down by a factor of 5 (660/136 = 4.9, 1331/242 = 5.5). netblast 127.0.0.1 5001 5 10 (localhost, port 5001, 5-byte tinygrams for 10 s): 537 kpps sent, 0 kpps dropped # before this patch (CPU use 1.3) 136 kpps sent, 0 kpps dropped # after (CPU use 2.1) (Pure software overheads. It uses 1.6 times as much CPU to go 4 times slower). netblast 192.168.2.8 (low end PCI33 lem on low latency 1 Gbps LAN) 275 kpps sent, 1045 kpps dropped # before (CPU use 1.3) 245 kpps sent, 0 kpps dropped # after (CPU use 1.3) (The hardware can't do anywhere near line rate of ~1500 kpps, so this becomes a benchmark of syscalls and dropping packets. The change makes FreeBSD so slow that 8 CPUs at 4.08 can't saturate a low end PCI33 NIC (the hardware saturates at about 282 kpps for tx and about 400 kpps for rx)). netblast 192.168.2.8 (low end PCIe em on low latency 1 Gbps LAN) 1316 kpps sent, 3 kpps dropped # before (CPU use 1.6) 243 kpps sent, 0 kpps dropped # after (CPU use 1.2) This is seriously slower for the most useful case. It reduces a system that could almost reach line rate using about 2 of 8 CPUs at 4 GHz to one that that is slower than with 1 CPU at 2 GHz (the latter saturates in software at about 640 kpps in old versions of FreeBSD at at about 400 kpps in -current). Initial debugging of the crash: it crashes on the first pmap_kenter() in getmemsize(). I configure debug.late_console to 0. That works, and without it getmemsize() can't even be debugged since it is after console initialization and ddb entry with -d. In getmemsize(), of course all the preload calls return 0 and smapbase is NULL. Then vm86 bios calls work and give basemem = 0x276. Then basemem_setup() is called and it returns. Then pmap_kenter() is called and it crashes: Stopped at getmemsize+0xb3: pushl $0x1000 Stopped at getmemsize+0xb8: pushl $0x1000 Stopped at getmemsize+0xbd: call pmap_kenter Stopped at pmap_kenter: pushl %ebp Stopped at pmap_kenter+0x1: movl %esp,%ebp Stopped at pmap_kenter+0x3: movl 0x8(%ebp),%eax Stopped at pmap_kenter+0x6: shrl $0xc,%eax Stopped at pmap_kenter+0x9: movl 0xc(%ebp),%edx Stopped at pmap_kenter+0xc: orl $0x3,%edx Stopped at pmap_kenter+0xf: movl %edx,PTmap(,%eax,4) The last instruction crashes because PTmap is not mapped at this point: db> p/x $edx 1003 db> p/x PTmap ff800000 db> p/x $eax 1 db> x/x PTmap PTmap:KDB: reentering KDB: stack backtrace: db_trace_self_wrapper(cec5cb,1420a04,c6de83,1420978,1,...) at db_trace_self_wrapper+0x24/frame 0x142095c kdb_reenter(1420978,1,ff80003a,1420998,8f1419,...) at kdb_reenter+0x24/frame 0x1420968 trap(1420a10) at trap+0xa0/frame 0x1420a04 calltrap() at calltrap+0x8/frame 0x1420a04 --- trap 0xc, eip = 0xc5c394, esp = 0x1420a50, ebp = 0x1420a88 --- db_read_bytes(ff800001,3,1420aa0) at db_read_bytes+0x29/frame 0x1420a88 db_get_value(ff800000,4,0,0,d2d304,...) at db_get_value+0x20/frame 0x1420ab4 db_examine(ff800000,1,ffffffff,1420b00) at db_examine+0x144/frame 0x1420ae4 db_command(cb1d99,1420be4,8f0f01,d1d28a,0,...) at db_command+0x20a/frame 0x1420b90 db_command_loop(d1d28a,0,1420bac,1420b9c,1420be4,...) at db_command_loop+0x55/frame 0x1420b9c db_trap(a,ffff4ff0,1,1,80046,...) at db_trap+0xe1/frame 0x1420be4 kdb_trap(a,ffff4ff0,1420cc4) at kdb_trap+0xb1/frame 0x1420c10 trap(1420cc4) at trap+0x523/frame 0x1420cb8 calltrap() at calltrap+0x8/frame 0x1420cb8 --- trap 0xa, eip = 0xc65a4a, esp = 0x1420d04, ebp = 0x1420d04 --- pmap_kenter(1000,1000,1429000,8efe13,0,...) at pmap_kenter+0xf/frame 0x1420d04 getmemsize(1,5a8807ff,ee,59a80097,ee,...) at getmemsize+0xc2/frame 0x1420fc4 init386(1428000) at init386+0x2bb/frame 0x1420ff4 btext() at btext+0x55 *** error reading from address ff800000 *** --More-- KDB: reentering KDB: stack backtrace: db_trace_self_wrapper(cec5cb,1420ab4,8ee255,cb1923,ff800000,...) at db_trace_self_wrapper+0x24/frame 0x1420a7c kdb_reenter(cb1923,ff800000,0) at kdb_reenter+0x24/frame 0x1420a88 db_get_value(ff800000,4,0,0,d2d304,...) at db_get_value+0x3a/frame 0x1420ab4 db_examine(ff800000,1,ffffffff,1420b00) at db_examine+0x144/frame 0x1420ae4 db_command(cb1d99,1420be4,8f0f01,d1d28a,0,...) at db_command+0x20a/frame 0x1420b90 db_command_loop(d1d28a,0,1420bac,1420b9c,1420be4,...) at db_command_loop+0x55/frame 0x1420b9c db_trap(a,ffff4ff0,1,1,80046,...) at db_trap+0xe1/frame 0x1420be4 kdb_trap(a,ffff4ff0,1420cc4) at kdb_trap+0xb1/frame 0x1420c10 trap(1420cc4) at trap+0x523/frame 0x1420cb8 calltrap() at calltrap+0x8/frame 0x1420cb8 --- trap 0xa, eip = 0xc65a4a, esp = 0x1420d04, ebp = 0x1420d04 --- pmap_kenter(1000,1000,1429000,8efe13,0,...) at pmap_kenter+0xf/frame 0x1420d04 getmemsize(1,5a8807ff,ee,59a80097,ee,...) at getmemsize+0xc2/frame 0x1420fc4 init386(1428000) at init386+0x2bb/frame 0x1420ff4 btext() at btext+0x55 db> Bruce From owner-freebsd-amd64@freebsd.org Sat Mar 31 23:23:40 2018 Return-Path: Delivered-To: freebsd-amd64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6D614F6510E for ; Sat, 31 Mar 2018 23:23:40 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 03EFF7BDE9 for ; Sat, 31 Mar 2018 23:23:40 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id B22B8F6510B; Sat, 31 Mar 2018 23:23:39 +0000 (UTC) Delivered-To: amd64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9FD83F6510A; Sat, 31 Mar 2018 23:23:39 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 16E387BDE6; Sat, 31 Mar 2018 23:23:38 +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 w2VNNS5u034732 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 1 Apr 2018 02:23:31 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w2VNNS5u034732 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w2VNNSjq034731; Sun, 1 Apr 2018 02:23:28 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 1 Apr 2018 02:23:28 +0300 From: Konstantin Belousov To: Dimitry Andric Cc: Bruce Evans , current@freebsd.org, amd64@freebsd.org, bde@freebsd.org Subject: Re: i386 4/4 change Message-ID: <20180331232328.GS1774@kib.kiev.ua> References: <20180331102901.GN1774@kib.kiev.ua> <20180401004833.L3296@besplex.bde.org> <3FAD36FD-FA90-49F6-9141-B9CCCCA2BF00@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FAD36FD-FA90-49F6-9141-B9CCCCA2BF00@FreeBSD.org> User-Agent: Mutt/1.9.4 (2018-02-28) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.25 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, 31 Mar 2018 23:23:40 -0000 On Sun, Apr 01, 2018 at 01:05:57AM +0200, Dimitry Andric wrote: > I haven't yet run any performance tests, I'll try building world and a > few large ports tomorrow. General operation from the command line does > not feel "sluggish" in any way, however. I just updated the review with some changes which should have effect on the copyout performance.