From owner-freebsd-stable@FreeBSD.ORG Sun Jan 31 16:28:58 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC7461065694; Sun, 31 Jan 2010 16:28:58 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 2AF848FC14; Sun, 31 Jan 2010 16:28:57 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.3/8.14.3/ALCHEMY.FRANKEN.DE) with ESMTP id o0VGSsBD009963; Sun, 31 Jan 2010 17:28:54 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.3/8.14.3/Submit) id o0VGSsoE009962; Sun, 31 Jan 2010 17:28:54 +0100 (CET) (envelope-from marius) Date: Sun, 31 Jan 2010 17:28:54 +0100 From: Marius Strobl To: John Baldwin Message-ID: <20100131162854.GC77522@alchemy.franken.de> References: <20100126073336.GA1955@server.vk2pj.dyndns.org> <201001260946.44977.jhb@freebsd.org> <20100126183756.GA40779@alchemy.franken.de> <201001261510.59667.jhb@freebsd.org> <20100127063649.GA1889@server.vk2pj.dyndns.org> <20100127115229.GD40779@alchemy.franken.de> <20100131010618.GA1864@server.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100131010618.GA1864@server.vk2pj.dyndns.org> User-Agent: Mutt/1.4.2.3i Cc: rmacklem@freebsd.org, dfr@freebsd.org, freebsd-stable@freebsd.org, Peter Jeremy Subject: Re: uma_zalloc_arg complaining about non-sleepable locks X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2010 16:28:58 -0000 On Sun, Jan 31, 2010 at 12:06:18PM +1100, Peter Jeremy wrote: > Sorry for the delay, I was trying to avoid rebooting my server. > I've setup a similar environment in VirtualBox to test it. > > On 2010-Jan-27 12:52:29 +0100, Marius Strobl wrote: > >Ah, I forgot that using nfsm_aligned() causes nfs_realign() to > >be a NOP on architectures without strict alignment requirements > >for performance reasons. That's generally fine but unfortunately > >that way you don't actually exercise the code which caused the > >problem before (unfortunately I still don't manage to hit the > >unaligned case myself). > > >Could you please test with #ifdef __NO_STRICT_ALIGNMENT replaced > >with #if 0 in sys/nfs/nfs_common.h? The vfs.nfs.realign_count > >counter should also increase then. > > I'm not sure what triggers the unaligned case either - I tried > roughly "tar -cf - -C /mnt/usr src | tar -xf - -C /mnt/tmp" and > that caused some unaligned accesses (but also completely wedged > the VBox host). I also tried copying a pile of files off my > NFS client (FreeBSD-8.x/i386) and that also triggered some > unaligned accesses without any errors being reported. > > Currently, I have: > vfs.nfs.realign_count: 12 > vfs.nfs.realign_test: 188817 > > I'd say that your patch works. John, are you okay with that patch? http://people.freebsd.org/~marius/fha_extract_info_realign2.diff It's intention is to: - Move nfs_realign() from the NFS client to the shared NFS code and remove the NFS server version in order to reduce code duplication. The shared version now uses a second parameter how, which is passed on to m_get(9) and m_getcl(9) as the server used M_WAIT while the client requires M_DONTWAIT, and replaces the the previously unused parameter hsiz. - Change nfs_realign() to use nfsm_aligned() so as with other NFS code the alignment check isn't actually performed on platforms without strict alignment requirements for performance reasons because as the comment suggests only occasionally occurs with TCP. - Change fha_extract_info() to use nfs_realign() with M_NOWAIT rather than M_DONTWAIT because it's called with the RPC sp_lock held. The only downside of the shared nfs_realign() are the combined SYSCTL counters but the fact we incremented them non-atomically so far I think already indicates that their intention only is a rough indication rather than exact values for client and server. Marius