From owner-svn-src-all@FreeBSD.ORG Fri Apr 24 06:00:19 2015 Return-Path: Delivered-To: svn-src-all@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 31EB6CE8; Fri, 24 Apr 2015 06:00:19 +0000 (UTC) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (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 0239D1867; Fri, 24 Apr 2015 06:00:19 +0000 (UTC) Received: by iebrs15 with SMTP id rs15so76927477ieb.3; Thu, 23 Apr 2015 23:00:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=gHnhLvzhQf0I5x8tWCGWRwil018ZTB1aP1xpLnJDxXc=; b=uUmR2Pd6CE4A6hYVPvET6AfKZgsWDuO4wlm4eUcc9ZkXmaVE35SHBLEX4pG3U3tUiA T+1pf/kA78NOM5n6rWZlVko6gpe+h8xjKtbT23TGO4N6tBdnOtDKh49UHPx/E5s9W7R2 n7KvdIESb2OiMgnIc+5Vgwu3HuqyX4bcqX462Ny/xJV4P0+9ByAwFVlTCQiHzel9Rkf0 k9U86ag89qbbRMVieKsOTY5Cm3gI6Y8/5AR+cVOdqIfL67NnUFz4ykAu58FnyGfLl/nC qvoM8CWcwGFiZr1Aozxct+DZo7dhSvC8Kdq8B4/XQVUB1tFMaQe0l7A1itPTV7FlnBiH FNqQ== MIME-Version: 1.0 X-Received: by 10.107.136.25 with SMTP id k25mr8569479iod.88.1429855218034; Thu, 23 Apr 2015 23:00:18 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.38.133 with HTTP; Thu, 23 Apr 2015 23:00:17 -0700 (PDT) In-Reply-To: References: <201504120621.t3C6LxAV095209@svn.freebsd.org> <5B48434B-EA97-45B3-BC4E-B039A868186B@yahoo.com> <4E109480-FD27-4C7F-8B5F-B1DB2232CD3D@yahoo.com> <20150423192819.GA13122@dchagin.static.corbina.net> Date: Thu, 23 Apr 2015 23:00:17 -0700 X-Google-Sender-Auth: zr7-ilGzD7kwJH2J1vlqI-LuYWY Message-ID: Subject: Re: svn commit: r281451 - head/sys/vm From: Adrian Chadd To: Scott Long Cc: Chagin Dmitry , "src-committers@freebsd.org" , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 06:00:19 -0000 On 23 April 2015 at 22:26, Scott Long wrote: > >> On Apr 23, 2015, at 1:28 PM, Chagin Dmitry wrote: >> >> On Thu, Apr 23, 2015 at 12:49:51PM -0600, Scott Long wrote: >>> >>>> On Apr 23, 2015, at 6:19 AM, Scott Long wrote: >>>> >>>>> >>>>> On Apr 12, 2015, at 12:21 AM, Dmitry Chagin wro= te: >>>>> >>>>> Author: dchagin >>>>> Date: Sun Apr 12 06:21:58 2015 >>>>> New Revision: 281451 >>>>> URL: https://svnweb.freebsd.org/changeset/base/281451 >>>>> >>>>> Log: >>>>> Rework r281162. Indeed, the flexible array member is preferable here. >>>>> >>>>> Suggested by: Justin T. Gibbs >>>>> >>>>> MFC after: 3 days >>>>> >>>>> Modified: >>>>> head/sys/vm/uma_core.c >>>>> head/sys/vm/uma_int.h >>>> >>>> There???s still something wrong with this. I have a machine with 28 c= ores (56 with hyperthreading) and 256GB of RAM, and ever since you committe= d r281162, it panics early in boot with a failed assertion. It looks like = the first few members of a uma_slab_t are getting overwritten accidentally,= and somehow the padding of the extra member in the uma_zone_t was previous= ly protecting it. I don???t know the exact cause yet, but I must ask that = you revert to r281161 in HEAD and stable/10 until the problem is resolved. >>>> >>> >>> I think the problem is that the masterzone_k and masterzone_z objects t= hat are statically allocated in uma_core.c no longer have space for the uz_= cpu field, but uma_zalloc_arg() always assumes that it???s there. Early in= boot when the ???kegs' and ???zones??? zones are being initialized, there?= ??s only 1 CPU so pre-allocating 1 uz_cpu element in the uma_zone is enough= . I can???t see any way around this without significantly changing how uma= _zalloc_arg() treats per-cpu caches. I think it???s best to revert this ch= ange. >>> >> Hi, >> they initialized in uma_startup() and not used before. >> I have a private converstion with a man which stable/10 hangs in vm_mem_= init().\ >> with my commit. weird. >> >> I do not object to revert, but give me a chance to figure out what's goi= ng on. > > With INVARIANTS enabled, the system will panic. Without it, it will spin= in vm_mem_init(), as you noted. Even if it=E2=80=99s not happening to eve= ryone, it=E2=80=99s a serious problem for such a minor anticipated benefit.= I must insist that it be reverted. Hi, +1 - please revert the patch for now and figure it out locally. Having -HEAD broken is very annoying. -a