Re: VMM sh: time sleep 30 takes 56 seconds
On Tue, Oct 23, 2018 at 04:47:06AM +, Mike Larkin wrote: > On Mon, Oct 22, 2018 at 02:52:42AM -0200, Daniel Bolgheroni wrote: > > On Fri, Oct 19, 2018 at 04:16:51AM +, Mike Larkin wrote: > > > On Thu, Oct 18, 2018 at 10:34:20PM -0300, Daniel Bolgheroni wrote: > > > > On Wed, Oct 17, 2018 at 08:42:46PM +, Mike Larkin wrote: > > > > > A 1000Hz host helps here. I get 10.32s real time on sleep 10 with > > > > > that setting. > > > > > > > > > > Note that qemu behaves the same way on OpenBSD. > > > > > > > > OK, the output is still slow when on serial, but things improved > > > > > > Is the console baudrate 9600 or 115200? > > > > It's running at 115200. > > > > $ vmctl start 1 -c > > Connected to /dev/ttyp7 (speed 115200) > > ^^^ if this is what you are using to determine that, I'd ask you to ensure > that you stty com0 115200 in /etc/boot.conf and that the /etc/ttys line > has 115200 for the console also. The baudrate from the output of the 'cu' > used by 'vmctl console' always prints 115200 in this case, even if vmd > is only outputting at 9600. Yes, it was my assumption. I already had 'stty com0 115200' in /etc/boot.conf and now adjusted /etc/ttys to 115200 where appropriate. And things improved: 9600 in /etc/ttys: # time cat /etc/ttys (...) 1m09.27s real 0m00.00s user 0m00.00s system # 115200 in /etc/ttys: # time cat /etc/ttys 0m11.66s real 0m00.00s user 0m00.00s system # As for comparison, I made the same test connected to a Orange Pi Zero, also at 115200, using a USB-to-serial converter uftdi(4): # time cat /etc/ttys 0m04.03s real 0m00.00s user 0m00.00s system # I don't know if this is somehow related to interrupts previously discussed and, in these cases, it's running -current snapshots, e.g. HZ=100. Thank you. -- db
Re: VMM sh: time sleep 30 takes 56 seconds
On Mon, Oct 22, 2018 at 02:52:42AM -0200, Daniel Bolgheroni wrote: > On Fri, Oct 19, 2018 at 04:16:51AM +, Mike Larkin wrote: > > On Thu, Oct 18, 2018 at 10:34:20PM -0300, Daniel Bolgheroni wrote: > > > On Wed, Oct 17, 2018 at 08:42:46PM +, Mike Larkin wrote: > > > > A 1000Hz host helps here. I get 10.32s real time on sleep 10 with that > > > > setting. > > > > > > > > Note that qemu behaves the same way on OpenBSD. > > > > > > OK, the output is still slow when on serial, but things improved > > > > Is the console baudrate 9600 or 115200? > > It's running at 115200. > > $ vmctl start 1 -c > Connected to /dev/ttyp7 (speed 115200) ^^^ if this is what you are using to determine that, I'd ask you to ensure that you stty com0 115200 in /etc/boot.conf and that the /etc/ttys line has 115200 for the console also. The baudrate from the output of the 'cu' used by 'vmctl console' always prints 115200 in this case, even if vmd is only outputting at 9600. -ml > [ using 2145656 bytes of bsd ELF symbol table ] > Copyright (c) 1982, 1986, 1989, 1991, 1993 > The Regents of the University of California. All rights reserved. > Copyright (c) 1995-2018 OpenBSD. All rights reserved. https://www.OpenBSD.org > > OpenBSD 6.4 (GENERIC.MP) #364: Thu Oct 11 13:30:23 MDT 2018 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 520093696 (496MB) > avail mem = 495116288 (472MB) > > (...) > > Thank you. > > -- > db
Re: VMM sh: time sleep 30 takes 56 seconds
On Fri, Oct 19, 2018 at 04:16:51AM +, Mike Larkin wrote: > On Thu, Oct 18, 2018 at 10:34:20PM -0300, Daniel Bolgheroni wrote: > > On Wed, Oct 17, 2018 at 08:42:46PM +, Mike Larkin wrote: > > > A 1000Hz host helps here. I get 10.32s real time on sleep 10 with that > > > setting. > > > > > > Note that qemu behaves the same way on OpenBSD. > > > > OK, the output is still slow when on serial, but things improved > > Is the console baudrate 9600 or 115200? It's running at 115200. $ vmctl start 1 -c Connected to /dev/ttyp7 (speed 115200) [ using 2145656 bytes of bsd ELF symbol table ] Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2018 OpenBSD. All rights reserved. https://www.OpenBSD.org OpenBSD 6.4 (GENERIC.MP) #364: Thu Oct 11 13:30:23 MDT 2018 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 520093696 (496MB) avail mem = 495116288 (472MB) (...) Thank you. -- db
Re: VMM sh: time sleep 30 takes 56 seconds
On Thu, Oct 18, 2018 at 10:34:20PM -0300, Daniel Bolgheroni wrote: > On Wed, Oct 17, 2018 at 08:42:46PM +, Mike Larkin wrote: > > A 1000Hz host helps here. I get 10.32s real time on sleep 10 with that > > setting. > > > > Note that qemu behaves the same way on OpenBSD. > > OK, the output is still slow when on serial, but things improved Is the console baudrate 9600 or 115200? > with 1000 Hz. I was going to ask why 1000 Hz isn't the default > then, but got the response. I'll leave here for reference: > > https://openbsd.amsterdam/clock.html > > Thank you. > > # for i in $(jot 10); do > > time sleep 30; > > done > 0m33.67s real 0m00.00s user 0m00.00s system > 0m33.96s real 0m00.00s user 0m00.00s system > 0m33.92s real 0m00.00s user 0m00.00s system > 0m33.62s real 0m00.00s user 0m00.00s system > 0m33.66s real 0m00.00s user 0m00.00s system > 0m33.64s real 0m00.00s user 0m00.00s system > 0m33.61s real 0m00.00s user 0m00.00s system > 0m33.85s real 0m00.00s user 0m00.00s system > 0m33.97s real 0m00.00s user 0m00.00s system > 0m33.74s real 0m00.00s user 0m00.00s system > # > > -- > db >
Re: VMM sh: time sleep 30 takes 56 seconds
On Wed, Oct 17, 2018 at 08:42:46PM +, Mike Larkin wrote: > A 1000Hz host helps here. I get 10.32s real time on sleep 10 with that > setting. > > Note that qemu behaves the same way on OpenBSD. OK, the output is still slow when on serial, but things improved with 1000 Hz. I was going to ask why 1000 Hz isn't the default then, but got the response. I'll leave here for reference: https://openbsd.amsterdam/clock.html Thank you. # for i in $(jot 10); do > time sleep 30; > done 0m33.67s real 0m00.00s user 0m00.00s system 0m33.96s real 0m00.00s user 0m00.00s system 0m33.92s real 0m00.00s user 0m00.00s system 0m33.62s real 0m00.00s user 0m00.00s system 0m33.66s real 0m00.00s user 0m00.00s system 0m33.64s real 0m00.00s user 0m00.00s system 0m33.61s real 0m00.00s user 0m00.00s system 0m33.85s real 0m00.00s user 0m00.00s system 0m33.97s real 0m00.00s user 0m00.00s system 0m33.74s real 0m00.00s user 0m00.00s system # -- db
Re: VMM sh: time sleep 30 takes 56 seconds
On Sat, Oct 13, 2018 at 07:37:49PM -0300, Daniel Bolgheroni wrote: > On Sat, Oct 13, 2018 at 01:08:23AM +, Jordan Geoghegan wrote: > > Hello, > > > > Not sure if this is a bug or not, so I thought I would ask misc@ first. > > > > I was writing a script in my vmm guest that involved killing and restarting > > a long running process every hour using sleep "3600", and I noticed it ended > > up sleeping for 2 hours and 56 minutes, rather than an hour. > > > > To test, I ran "time sleep 30" and got this result: > > > > vmm$ time sleep 30 > > 0m57.50s real 0m00.00s user 0m00.00s system > > > > When run on bare metal, I get this result: > > > > server$ time sleep 30 > > 0m30.00s real 0m00.00s user 0m00.00s system > > > > I have "sysctl kern.timecounter.hardware=tsc" set in the vm to prevent clock > > drift, otherwise the vm clock runs at around half speed. > > > > When "time sleep 30" is run on a vm without "sysctl > > kern.timecounter.hardware=tsc" set, it reports the correct amount of time > > being spent sleeping, but since the clock runs at around half speed without > > tsc enabled, it still ends up sleeping for almost a minute. > > > > The host machine is running 6.3 stable, the guest is running the latest > > snapshot. I tried running a 6.3-stable guest with the same results. > > > > Has this been fixed in current? I don't have a vmm capable machine available > > running current, I only own spare macppc and i386 hardware which runs > > current. > > I get the same results as yours also with a -current vm running on > -current, also with kern.timecounter.hardware=tsc on the vm. > > # time sleep 30 > 0m59.99s real 0m00.00s user 0m00.00s system > # time sleep 30 > 1m00.30s real 0m00.00s user 0m00.00s system > # time sleep 30 > 1m00.30s real 0m00.00s user 0m00.00s system > # > > I don't know if it's somehow related to the same interrupt thing, but I > also get a slow scroll when attached to the console. A 1000Hz host helps here. I get 10.32s real time on sleep 10 with that setting. Note that qemu behaves the same way on OpenBSD. -ml
Re: VMM sh: time sleep 30 takes 56 seconds
On Sat, Oct 13, 2018 at 01:08:23AM +, Jordan Geoghegan wrote: > Hello, > > Not sure if this is a bug or not, so I thought I would ask misc@ first. > > I was writing a script in my vmm guest that involved killing and restarting > a long running process every hour using sleep "3600", and I noticed it ended > up sleeping for 2 hours and 56 minutes, rather than an hour. > > To test, I ran "time sleep 30" and got this result: > > vmm$ time sleep 30 > 0m57.50s real 0m00.00s user 0m00.00s system > > When run on bare metal, I get this result: > > server$ time sleep 30 > 0m30.00s real 0m00.00s user 0m00.00s system > > I have "sysctl kern.timecounter.hardware=tsc" set in the vm to prevent clock > drift, otherwise the vm clock runs at around half speed. > > When "time sleep 30" is run on a vm without "sysctl > kern.timecounter.hardware=tsc" set, it reports the correct amount of time > being spent sleeping, but since the clock runs at around half speed without > tsc enabled, it still ends up sleeping for almost a minute. > > The host machine is running 6.3 stable, the guest is running the latest > snapshot. I tried running a 6.3-stable guest with the same results. > > Has this been fixed in current? I don't have a vmm capable machine available > running current, I only own spare macppc and i386 hardware which runs > current. I get the same results as yours also with a -current vm running on -current, also with kern.timecounter.hardware=tsc on the vm. # time sleep 30 0m59.99s real 0m00.00s user 0m00.00s system # time sleep 30 1m00.30s real 0m00.00s user 0m00.00s system # time sleep 30 1m00.30s real 0m00.00s user 0m00.00s system # I don't know if it's somehow related to the same interrupt thing, but I also get a slow scroll when attached to the console. OpenBSD 6.4 (GENERIC.MP) #364: Thu Oct 11 13:30:23 MDT 2018 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8451125248 (8059MB) avail mem = 8185724928 (7806MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xdae9c000 (64 entries) bios0: vendor LENOVO version "8DET73WW (1.43 )" date 10/12/2016 bios0: LENOVO 4291MV7 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC SSDT SSDT SSDT HPET APIC MCFG ECDT ASF! TCPA SSDT SSDT DMAR UEFI UEFI UEFI acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP4(S4) EXP7(S4) EHC1(S3) EHC2(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2492.33 MHz, 06-2a-07 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2491.91 MHz, 06-2a-07 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2491.91 MHz, 06-2a-07 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2491.91 MHz, 06-2a-07 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xf800, bus 0-63 acpiec0
VMM sh: time sleep 30 takes 56 seconds
Hello, Not sure if this is a bug or not, so I thought I would ask misc@ first. I was writing a script in my vmm guest that involved killing and restarting a long running process every hour using sleep "3600", and I noticed it ended up sleeping for 2 hours and 56 minutes, rather than an hour. To test, I ran "time sleep 30" and got this result: vmm$ time sleep 30 0m57.50s real 0m00.00s user 0m00.00s system When run on bare metal, I get this result: server$ time sleep 30 0m30.00s real 0m00.00s user 0m00.00s system I have "sysctl kern.timecounter.hardware=tsc" set in the vm to prevent clock drift, otherwise the vm clock runs at around half speed. When "time sleep 30" is run on a vm without "sysctl kern.timecounter.hardware=tsc" set, it reports the correct amount of time being spent sleeping, but since the clock runs at around half speed without tsc enabled, it still ends up sleeping for almost a minute. The host machine is running 6.3 stable, the guest is running the latest snapshot. I tried running a 6.3-stable guest with the same results. Has this been fixed in current? I don't have a vmm capable machine available running current, I only own spare macppc and i386 hardware which runs current. Cheers, Jordan dmesg of the host machine: OpenBSD 6.3 (GENERIC.MP) #10: Wed Aug 22 16:42:31 CEST 2018 r...@syspatch-63-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 68664565760 (65483MB) avail mem = 66576482304 (63492MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xec0d0 (43 entries) bios0: vendor American Megatrends Inc. version "P1.80" date 12/09/2013 bios0: ASRock EP2C602 acpi0 at bios0: rev 2 acpi0: sleep states S0 S1 S4 S5 acpi0: tables DSDT FACP APIC FPDT MCFG AAFT SRAT SLIT HPET PRAD SPMI SSDT SPCR EINJ ERST HEST BERT acpi0: wakeup devices UR11(S4) UR12(S4) P0P9(S1) EUSB(S4) USBE(S4) PEX0(S4) PEX1(S4) PEX2(S4) PEX3(S4) PEX4(S4) PEX5(S4) PEX6(S4) PEX7(S4) GBE_(S4) NPE1(S4) NPE2(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz, 2000.27 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache acpitimer0: recalibrated TSC frequency 200159 Hz cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz, 2000.00 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz, 2000.00 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz, 2000.00 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 3, package 0 cpu4 at mainbus0: apid 8 (application processor) cpu4: Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz, 2000.00 MHz cpu4: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu4: 256KB 64b/line 8-way L2 cache cpu4: smt 0, core 4, package 0 cpu5 at mainbus0: apid 10 (application proces