From owner-freebsd-hackers@FreeBSD.ORG Sun Sep 28 03:55:36 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5CBCF51C for ; Sun, 28 Sep 2014 03:55:36 +0000 (UTC) Received: from mail-ig0-f173.google.com (mail-ig0-f173.google.com [209.85.213.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 27F1DB3E for ; Sun, 28 Sep 2014 03:55:35 +0000 (UTC) Received: by mail-ig0-f173.google.com with SMTP id uq10so491469igb.6 for ; Sat, 27 Sep 2014 20:55:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=J72CyKVfY3Z4G/L31piNy4Q6ODQG790oE6CqB5/pPOY=; b=c75NgR9Af+tUdp0PTjAMg+brYqa6fuiopS9x45jTIgU0ziuCE/M4LLef0k8ciefK8T foK29ieYm2gHRoQN8UblxnuQSdFQUx9N+rkV8T1ss7MbECiHVBKF5HZuPoZR/4FEOqrT cff8LSkQhrE1jZvmeOcQ9f0i+qHJ9YXJkK6TvhYw31ZTMvHAz0cjC0KZi5FkanIMjEzN i4vKD+Zlp9VurC3XwuhLl8/grgEXv4QfxvZ2xRfmo2H7BHNElN6MVUt2kDIoFM9xjxGb tGz01PmHnXy5wgKpxR7FV6o4lByCIJItZWLHiMnRCtLxUdPtfUhhnD7WJmj5Pp0dU6gn dxjg== X-Gm-Message-State: ALoCoQmtzNx6Azjdfyj/QfxE0WDj+B1vgpP1Gi+GMn3yjKJYxM2Q5C74thF2NXbiFYiMPndAIL5x X-Received: by 10.42.180.5 with SMTP id bs5mr287002icb.70.1411874716370; Sat, 27 Sep 2014 20:25:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.9.67 with HTTP; Sat, 27 Sep 2014 20:24:56 -0700 (PDT) X-Originating-IP: [67.198.113.68] In-Reply-To: <0EAA931C1DCF4897A45D86C7CBDCA11C@multiplay.co.uk> References: <0EAA931C1DCF4897A45D86C7CBDCA11C@multiplay.co.uk> From: Bryan Venteicher Date: Sat, 27 Sep 2014 22:24:56 -0500 Message-ID: Subject: Re: Change uma_mtx to rwlock To: Steven Hartland Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2014 03:55:36 -0000 On Sat, Sep 27, 2014 at 9:30 PM, Steven Hartland wrote: > ----- Original Message ----- From: "Bryan Venteicher" < > bryanv@daemoninthecloset.org> > >> On Sat, Sep 27, 2014 at 8:42 PM, Steven Hartland > > >> wrote: >> >> Out of interest does that include ZFS and its UMA zones, as we're >>> currently >>> investigating issues around this. >>> >>> >>> Yes, I believe this would include ZFS's zones too >> > > It would but I was more curious as it if you had seen the delay > specifically on > the ZFS zone or if it was other zones which triggered the issue for you? > > =E2=80=8BWe are using an old version of FreeBSD/ZFS, so our ZFS allocations= go through malloc instead of directly to UMA. For us, it was the cumulative effect of the number of UMA zones (buckets really) =E2=80=8Bthat lead to long hold times of the UMA mutex. ZFS related allocations were a significant part of that, but not typically the largest. > Regards > Steve >