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

[Eugene Grosbein]

13.12.2017 20:38, Rodney W. Grimes wrote:

> 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
> 
> 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.

I don't understand why you want to backout that. It changed nothing for amd64.
An i386 is still vulnerable to double faults just because of a network packet
processing path can overflow kstack for the GENERIC kernel.

If one has stripped-down kernel or just uses FreeBSD within safe environment
preventing it from such packets, there is still loader.conf to change kstack_pages
to any desired value for such special appliances that need lots of threads for i386.

And I don't think someone should expect to run dozen of VMs within i386 kernel
without some tuning. So please leave r326758 alone as it hardens FreeBSD in default setup
and this is more important.