From owner-freebsd-arm@FreeBSD.ORG Wed Jun 19 18:15:34 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 46D853FA; Wed, 19 Jun 2013 18:15:34 +0000 (UTC) (envelope-from zbb@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id B731B1682; Wed, 19 Jun 2013 18:15:33 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id 7001DC3CB7; Wed, 19 Jun 2013 20:15:26 +0200 (CEST) X-Virus-Scanned: by amavisd-new at semihalf.com Received: from smtp.semihalf.com ([213.17.239.109]) by localhost (smtp.semihalf.com [213.17.239.109]) (amavisd-new, port 10024) with ESMTP id dOmTgZ6v+Unl; Wed, 19 Jun 2013 20:15:25 +0200 (CEST) Received: from [10.0.2.117] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPSA id E85DEC3AB7; Wed, 19 Jun 2013 20:15:24 +0200 (CEST) Message-ID: <51C1F53B.2080502@semihalf.com> Date: Wed, 19 Jun 2013 20:15:23 +0200 From: Zbyszek Bodek Organization: Semihalf User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Kernel build fails on ARM: Cannot fork: Cannot allocate memory X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org, jeff@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 18:15:34 -0000 Hello, I've been trying to compile the kernel on my ARMv7 platform using the sources from the current FreeBSD HEAD. make buildkernel <.....> -j5 1/2 builds fails in the way described below: -------------------------------------------------------------------------- ing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/root/src/freebsd-arm-superpages/sys -I/root/src/freebsd-arm-superpages/sys/contrib/altq -I/root/src/freebsd-arm-superpages/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-thumb-interwork -ffreestanding -Werror /root/src/freebsd-arm-superpages/sys/ufs/ffs/ffs_snapshot.c Cannot fork: Cannot allocate memory *** [ffs_snapshot.o] Error code 2 1 error *** [buildkernel] Error code 2 1 error *** [buildkernel] Error code 2 1 error 5487.888u 481.569s 7:35.65 1310.0% 1443+167k 1741+5388io 221pf+0w -------------------------------------------------------------------------- The warning from std err is: -------------------------------------------------------------------------- vm_thread_new: kstack allocation failed vm_thread_new: kstack allocation failed -------------------------------------------------------------------------- I was trying to find out which commit is causing this (because I was previously working on some older revision) and using bisect I got to: -------------------------------------------------------------------------- Author: jeff Date: Tue Jun 18 04:50:20 2013 +0000 Refine UMA bucket allocation to reduce space consumption and improve performance. - Always free to the alloc bucket if there is space. This gives LIFO allocation order to improve hot-cache performance. This also allows for zones with a single bucket per-cpu rather than a pair if the entire working set fits in one bucket. - Enable per-cpu caches of buckets. To prevent recursive bucket allocation one bucket zone still has per-cpu caches disabled. - Pick the initial bucket size based on a table driven maximum size per-bucket rather than the number of items per-page. This gives more sane initial sizes. - Only grow the bucket size when we face contention on the zone lock, this causes bucket sizes to grow more slowly. - Adjust the number of items per-bucket to account for the header space. This packs the buckets more efficiently per-page while making them not quite powers of two. - Eliminate the per-zone free bucket list. Always return buckets back to the bucket zone. This ensures that as zones grow into larger bucket sizes they eventually discard the smaller sizes. It persists fewer buckets in the system. The locking is slightly trickier. - Only switch buckets in zalloc, not zfree, this eliminates pathological cases where we ping-pong between two buckets. - Ensure that the thread that fills a new bucket gets to allocate from it to give a better upper bound on allocation time. Sponsored by: EMC / Isilon Storage Division -------------------------------------------------------------------------- I checked this several times and this commits seems to be causing this. Does anyone observe similar behavior or have a solution? Best regards Zbyszek Bodek