Date: Mon, 11 Dec 2017 07:33:08 -0800 (PST) From: "Rodney W. Grimes" <freebsd@pdx.rh.CN85.dnsmgr.net> To: Konstantin Belousov <kostikbel@gmail.com> Cc: rgrimes@freebsd.org, Conrad Meyer <cem@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r326758 - in head/sys/i386: conf include Message-ID: <201712111533.vBBFX8sl081789@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <20171211152219.GL2272@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Mon, Dec 11, 2017 at 07:09:10AM -0800, Rodney W. Grimes wrote:
> > The current comment about a pcb, I thought that code was changed
> > so we only put the pointer to a pcb on the stack.
>
> pcb is on top of the stack, followed by the userspace FPU registers save
> area. I do not see any sense in existence of pcb in modern kernel, it is
> a remnant of the user area that was swappable. Currently pcb is swappable
> as well, but the value of this is much less then the overhead we pay by
> the stack space reduction.
How about KSTACK_PAGES should be KSTAKE_BYTES/PAGESIZE, and we
need a much better formula for define of KSTACK_BYTES so that
these facts are more accurately defined?
And a compile time assert if this ever growes to something unreasonable
that would cause other issues.
I fully agree with you that just bumping KSTACK_PAGES is very much
the wrong way to fix the i386 issue of certain code not running,
it is that code that should be examined for over usage of the stack.
I can assert that the base i386 system is very usable for tons of
things without this change, I have at least 30 VM's running FreeBSD
11.1/i386 in some very small footprints, typically 64MB, that have
zero issues. But then they are not using any of the code that
sited as problem areas.
> FPU save area is the on of the problem which makes us increase the amd64
> stack size, AVX or even AVX512 make the things much worse. It is unlikely
> that somebody would run 32bit kernel on machine capable of that extensions,
> i.e. Haswell or Skylake.
Your igonoring the virutalization world, host is a skylake or haswell, guest
is i386 as it has small memory needs and no use to waste half of all pointers.
We need to break the developers model that i386 is dead and that i386 is
not running on extremly modern hardware due to the factor of virtualization.
Output from one of my VM's running inside bhyve:
# uname -a
FreeBSD filestore.dnsmgr.net 11.1-RELEASE FreeBSD 11.1-RELEASE #0 r321309: Fri Jul 21 04:10:47 UTC 2017 root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC i386
# dmesg | head -24
Copyright (c) 1992-2017 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 11.1-RELEASE #0 r321309: Fri Jul 21 02:08:28 UTC 2017
root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64
FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 4.0.0)
VT(vga): resolution 640x480
info: [drm] Initialized drm 1.1.0 20060810
CPU: Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz (2494.39-MHz K8-class CPU)
Origin="GenuineIntel" Id=0x306a9 Family=0x6 Model=0x3a Stepping=9
Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
Features2=0x7fbae3bf<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND>
AMD Features=0x28100800<SYSCALL,NX,RDTSCP,LM>
AMD Features2=0x1<LAHF>
Structured Extended Features=0x281<FSGSBASE,SMEP,ERMS>
XSAVE Features=0x1<XSAVEOPT>
VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
TSC: P-state invariant, performance statistics
real memory = 12884901888 (12288 MB)
avail memory = 12114096128 (11552 MB)
Event timer "LAPIC" quality 600
ACPI APIC Table: <LENOVO TP-G2 >
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
--
Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201712111533.vBBFX8sl081789>