svn commit: r326809 - head/sys/dev/cardbus

[Rodney W. Grimes]

> > On Tue, Dec 12, 2017 at 12:39:38PM -0800, Rodney W. Grimes wrote:
> > > > New Revision: 326809
> > > > URL: https://svnweb.freebsd.org/changeset/base/326809
> > > > 
> > > > Log:
> > > >   1k objects on the stack are a bad idea. While it's likely safe in this
> > > >   context, it's also safe to allocate the memory and free it instead.
> > > >   
> > > >   Noticed by: Eugene Grosbein's script
> > > 
> > > YEA!!!  One down, 20 to go and then see how the kstack issue does?
> > > 
> > > And thank you for quickly fixing this.
> > 
> > It's very promising to see debloat-type of work having started.  On the
> > related note, what is current consensus with r326758, is it going to be
> > backed out and stack issues investigated and fixed?  I am worried since
> > kib@ had mentioned that he's "almost sure that [32-bit x86 workstation]
> > users would get troubles now" [*] and I'm one of them.
> 
> That I can not answer, but I can say I have just found the problem
> is NOT limited to i386, we can rather quickly blow up an amd64 system
> running a dozen or so VM's.
> 
> My bhyve host tossed a stack of these out last night:
> vm_thread_new: kstack allocation failed
> vm_thread_new: kstack allocation failed
> vm_thread_new: kstack allocation failed
> vm_thread_new: kstack allocation failed
> vm_thread_new: kstack allocation failed
> vm_thread_new: kstack allocation failed
> vm_thread_new: kstack allocation failed
> vm_thread_new: kstack allocation failed
> vm_thread_new: kstack allocation failed
> vm_thread_new: kstack allocation failed

Ok, ignore this, the console was connected to a vm, these
messages are infact from a vm running i386 11.1, just upgraded
from 11.0 to 11.1 so even between that step there is a regression
as I did not have these on the 11.0 system.

> ZFS has been tuned to leave 1.2* my total VM allocations free space
> of memory and I only had 10 out of 16 vm's running last night, so
> there is tons of free memory.  This is probalby KVA space starvation,
> though I thought that was pretty much a non issue on amd64.
> 
> I do think we should back out r326758 sooner rather than later,
> and if it got MFC'd or flagged for MFC kill that right now.
> 
> A regression test would also be nice that can push the system
> close to what the usable limit is, and that test should be run
> in a CI situtaion to make sure we keep it running.  This is a
> non trivial to do though as there are many work load patterns
> that can push the kernel towards stack space limits.
> 
> -- 
> Rod Grimes                                                 rgrimes at freebsd.org
-- 
Rod Grimes                                                 rgrimes at freebsd.org