From owner-svn-src-head@freebsd.org Mon Nov 2 04:13:50 2015 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 679BFA1E43E; Mon, 2 Nov 2015 04:13:50 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2E31E1A0F; Mon, 2 Nov 2015 04:13:50 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by igbdj2 with SMTP id dj2so46234430igb.1; Sun, 01 Nov 2015 20:13:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dw4/iwv1A+vpz6u+PEjFQBsE5PEYQg6IX5t0sYva268=; b=wKDTa8FU41wlx8WU5RYH6+LoS6vBoZGeBVGyh9sArrCf+I6qZvgLSQGHUjzqKlebyW gL9xiUMEMu6y6Raa9CNVTn9TbpHT8IRNU1Prl2tq9sVbiuoeFQYtIpqpsPHoOvnkjfy+ fmu8JQE65yfS8QDNUt5gseZJhc3QgEKXHwaSOGqI8CR3llR0fBQuLjkBxRnRggourPZA ob8Qyvf0drWpydFjHoy7irbLw++X3RBLMA1MvFry88KOVUQFrFXSzq/dakAu2iNO5M+c Fvilq9Wm3Y987n6ds0AQVKU9vea2RU9htb5lhbp0DEb2CHCfGLC7iEgbJtTK6T1nHVuW rIKw== MIME-Version: 1.0 X-Received: by 10.50.164.196 with SMTP id ys4mr9414091igb.37.1446437629699; Sun, 01 Nov 2015 20:13:49 -0800 (PST) Received: by 10.36.46.66 with HTTP; Sun, 1 Nov 2015 20:13:49 -0800 (PST) In-Reply-To: References: <201510140210.t9E2A79H056595@repo.freebsd.org> Date: Sun, 1 Nov 2015 20:13:49 -0800 Message-ID: Subject: Re: svn commit: r289279 - in head/sys: kern vm From: Adrian Chadd To: Jeff Roberson Cc: NGie Cooper , Jeff Roberson , Mark Johnston , Warner Losh , benno , "src-committers@freebsd.org" , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 04:13:50 -0000 On 1 November 2015 at 20:05, Jeff Roberson wrote: > On Sun, 1 Nov 2015, NGie Cooper wrote: > >> >>> On Nov 1, 2015, at 19:20, Adrian Chadd wrote: >>> >>> hiya jeff, >>> >>> this broke low-memory, no-swap boards (eg MIPS.) >>> >>> On a MIPS board (carambola2) with 32MB of RAM, just scp'ing a kernel >>> into the rootfs on USB hangs the system. After doing some digging, I >>> found this: >>> >>> >>> INTERNAL: Allocating one item from buf free cache(0x83fea7e0) >>> uma_zalloc_arg: Bucketzone returned NULL >>> INTERNAL: Allocating one item from buf free cache(0x83fea7e0) >>> uma_zalloc_arg: Bucketzone returned NULL >>> >>> .. and it was just stuck in a loop trying to allocate them, failing, >>> and trying to allocate them again. >>> >>> I'll see if I can reproduce it with a qemu emulator with sufficiently >>> low RAM so you don't need a MIPS router to reproduce it. >>> >>> It's sufficient to just start the scp; it runs out of RAM within a >>> couple of seconds. >>> >>> Any ideas? >> >> >> What happens if you change vfs.maxbufspace ? >> >> The reason that I?m noting is that (if I?m reading the code correctly), >> it?s now allocating 16 clean queues instead of 1 and each is up to >> vfs.maxbufspace size, which is 256MB per queue based on this line: >> >> + clean_queues = MIN(howmany(maxbufspace, 256*1024*1024), CLEAN_QUEUES); >> >> The 256MB amount seems like it should be a tunable, as well as the >> CLEAN_QUEUES #define? it?s a bit high for low memory platforms, i.e. >> platforms with <372MB of scratch space to play around with I?m guessing? > > > maxbufspace is still a global. It just makes N queues for every 256MB of > configured buffer cache size. > > We shouldn't be looping forever. It should sleep and try to re-allocate. > How many cpus are on the mips board? We may need to implement something to > directly flush the buf zone and disable the per-cpu caches when allocation > fails. It's a single CPU mips board (AR9331 SoC.) -adrian