Re: RELENG_7_0: vm_thread_new: kstack allocation failed

Previous thread: Re: page fault panic in scioctl and console-kit-daemon by Pawel Worach on Tuesday, January 22, 2008 - 2:26 pm. (15 messages)

Next thread: Performance Tracker project update by Erik Cederstrand on Wednesday, January 23, 2008 - 12:48 am. (1 message)
To: FreeBSD Current <freebsd-current@...>
Date: Tuesday, January 22, 2008 - 7:45 pm

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I have got a lot of this in dmesg output for RELENG_7_0 as of today:

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

Any idea?

Cheers,
- --
Xin LI <delphij@delphij.net> http://www.delphij.net/
FreeBSD - The Power to Serve!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (FreeBSD)

iD8DBQFHloAci+vbBBjt66ARAl+8AJ9MR39A2x4ynKQ06BOKAWEaoJfBVQCgkwDg
jTeZCc0rALWjABp2wOBK2u0=
=YRAd
-----END PGP SIGNATURE-----
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

To: <d@...>
Cc: FreeBSD Current <freebsd-current@...>
Date: Wednesday, January 23, 2008 - 1:12 am

Does it cause any problems aside from printing these messages ?
What workload do you put on the machine ?

The messages came from the failure of the kernel to allocate address
space for the kernel stack for a thread being created. Previously, the
system would panic encountering this situation.

This may happen due to kernel_map address space depletion, for instance,
by having a lot (on i386 machines with > 1Gb memory, ~40000) threads.

To: Kostik Belousov <kostikbel@...>
Cc: FreeBSD Current <freebsd-current@...>, <d@...>
Date: Wednesday, January 23, 2008 - 1:59 am

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

It was an rsync from NFS to ZFS with ~15M of files, and rsync will
consume basically all physical memory. I end up with some 2GB active,
4GB wired thing. (The system has 8GB of RAM), and I added a "make -j9

Yes, I knew, previously it just panic and hangs there, and thanks a lot

It seems that I have hit some sort of "leak" or some exhaustion issue.
Say, when the workload is gone, the system did not recover from the
situation, and reboot worked fine.

The system is sort of in production and it is about 20 miles away from
my office. Do you want me to do some experiments for this?

Cheers,
- --
Xin LI <delphij@delphij.net> http://www.delphij.net/
FreeBSD - The Power to Serve!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (FreeBSD)

iD8DBQFHltfEi+vbBBjt66ARAi+yAKC3HKy9YaOHNZK3l45NUVYDxc5EZQCfWOlN
rTaCDmEc9ZZoizRRdcBOFF4=
=/tP1
-----END PGP SIGNATURE-----
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

To: <d@...>
Cc: FreeBSD Current <freebsd-current@...>
Date: Wednesday, January 23, 2008 - 6:52 am

Yes, I want to know what exactly leaked. Ideally, I would like to see the
series of the output of the vmstat -z and vmstat -m for some time before
the system is bogged down. But, even the one snapshot of the vmstat -z/-m
output immediately before things stop working would be good to look at.

Output of the ps auxwwH is helpful too.

Previous thread: Re: page fault panic in scioctl and console-kit-daemon by Pawel Worach on Tuesday, January 22, 2008 - 2:26 pm. (15 messages)

Next thread: Performance Tracker project update by Erik Cederstrand on Wednesday, January 23, 2008 - 12:48 am. (1 message)