From owner-freebsd-hackers@freebsd.org Sun Jun 4 22:44:34 2017 Return-Path: Delivered-To: freebsd-hackers@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 E4E43BF147A for ; Sun, 4 Jun 2017 22:44:34 +0000 (UTC) (envelope-from vangyzen@FreeBSD.org) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [IPv6:2607:fc50:1000:7400:216:3eff:fe72:314f]) by mx1.freebsd.org (Postfix) with ESMTP id D0187641EB for ; Sun, 4 Jun 2017 22:44:34 +0000 (UTC) (envelope-from vangyzen@FreeBSD.org) Received: from ford.home.vangyzen.net (unknown [76.164.15.242]) by smtp.vangyzen.net (Postfix) with ESMTPSA id 437655646B for ; Sun, 4 Jun 2017 17:44:34 -0500 (CDT) To: FreeBSD Hackers From: Eric van Gyzen Subject: Function attribute for optimization level Message-ID: <85c47390-dd27-aa74-24fe-25a9a5352527@FreeBSD.org> Date: Sun, 4 Jun 2017 17:44:31 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2017 22:44:35 -0000 _thr_rtld_init() calls memcpy() for the sole purpose of resolving its PLT entry. With clang 4.0 and the current code, compiler optimization defeats this attempt by completely eliding the call. Other compilers or code might emit inline instructions instead of the library call, also defeating the purpose. I propose adding "__no_optimization" to sys/cdefs.h. The patch is below. Empirical testing shows that clang 3.7 and later support "optnone", and gcc 4.6 and later support "optimize()". Clang 3.4 does not support either, so it takes the define-to-empty case. I did not test clang 3.5 or 3.6. Side note: GCC 4.6 with optimize(0) on amd64 emits two movq instructions for memset(x,0,16), but GCC 5 emits a call to memset(). I have done no research to see if other popular codebases have such a definition. If you know of one, please tell me; I would gladly adopt an already common name for this proposal, for the sake of portability. Thanks in advance for your feedback. Eric diff --git a/sys/sys/cdefs.h b/sys/sys/cdefs.h index 9cdc03c861cb..e370f6d6459e 100644 --- a/sys/sys/cdefs.h +++ b/sys/sys/cdefs.h @@ -396,6 +396,14 @@ #define __unreachable() ((void)0) #endif +#if __has_attribute(optnone) +#define __no_optimization __attribute__((optnone)) +#elif __has_attribute(optimize) +#define __no_optimization __attribute__((optimize(0))) +#else +#define __no_optimization +#endif + /* XXX: should use `#if __STDC_VERSION__ < 199901'. */ #if !__GNUC_PREREQ__(2, 7) && !defined(__INTEL_COMPILER) #define __func__ NULL From owner-freebsd-hackers@freebsd.org Mon Jun 5 04:08:49 2017 Return-Path: Delivered-To: freebsd-hackers@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 BD4EEBF60EC for ; Mon, 5 Jun 2017 04:08:49 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from nm2-vm5.bullet.mail.ne1.yahoo.com (nm2-vm5.bullet.mail.ne1.yahoo.com [98.138.91.224]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9101F6FA74 for ; Mon, 5 Jun 2017 04:08:49 +0000 (UTC) (envelope-from pfg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1496635723; bh=Q3d68+5Z53Jry3Ab2nsu9Wp3qVNc95dK0a0mMcQuo5s=; h=To:From:Subject:Cc:Date:From:Subject; b=i0YhoevY1BUNF3kF3BJgNbB5Fx/hG8UqICsk2Eu8zV1IGwhJRrw86QRbrc4BI88Km6NB1Nafu+/igFS/wIfGP2MbCt4854PPfqslWiQdDAhfjpMC56g2Mr4+i2VibjeXGjsl3iQI5zFFGx2MnRYXQCjbYQFmyclYqF62fOTtc1aXYQ1o52dPfNmkYtQ3SvGW/YbpGqvT+vZB72i21D5gi5AZHQ09I0V1NRdFT95fxGnhE89GBKAZa7sB67WResjpgEJWD6uNFfK5AYtqom+Kj0QkDOyLGyD2WL+reSmdYS2TxDBcz+EHbyG6g384XWuliD6+k/tp34Q4URw3g7KFEw== Received: from [98.138.100.115] by nm2.bullet.mail.ne1.yahoo.com with NNFMP; 05 Jun 2017 04:08:43 -0000 Received: from [98.138.84.46] by tm106.bullet.mail.ne1.yahoo.com with NNFMP; 05 Jun 2017 04:08:43 -0000 Received: from [127.0.0.1] by smtp114.mail.ne1.yahoo.com with NNFMP; 05 Jun 2017 04:08:43 -0000 X-Yahoo-Newman-Id: 466092.92973.bm@smtp114.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: yP8ewOYVM1ntN5MnLpPqPBuw9hF3dMO0EjW1rT8FJSHZcL3 _u11WKdNXC84kiIRdHoROKtwFW7bsmSH29rtYWLqc0bwbxqjkFgG3MzNsjAn bnslAo9b8p9Ejn4ANjw3iulV1zqS8BIOPV.y3BRD8OyHD15dQ523KajXHVbY ge1AJa05HFyGgmzgYuD9ESHOEi8PFWcvt53IQzqrMw5iEETMcyCn0mfHc4Uv z2BUZpQgricDeodW_ckahUmGo9b58QATXskHcjTgyYn.CrRzhH.0zNXjP3M3 F38lrLTi6ZClIuxBUFSlE.D.1E6Rs7SDtX4nwz7mnYEhyykucLmXruqI_xgw QyDMqS76xmfamx4iy8cKMVCiWDP_DjleDr.q.X7z5nYBORoAtS8kTEI1Iawc 0zdompJ3s.uPHyMmbULS_wXdladur.7YpZnYrkWwoVT9hebEursCsmGuARml Wv1O5zDtdEodxPL.i40RuyXhs29E.wzNTn1Wlp4yjWEvgSWAjxHhCDXORSuh gk30YFF9BT7t8tuPcmdJk4tFMg3QdaDGVcx8M30bn_CrN X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf To: Eric van Gyzen From: Pedro Giffuni Subject: Re: Function attribute for optimization level Organization: FreeBSD Project Cc: FreeBSD Hackers Message-ID: Date: Sun, 4 Jun 2017 23:08:42 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Language: en-US Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 04:08:49 -0000 Hi Eric; It is a good idea : the nonopt attribute is useful in parts of the boot loader and probably in security-related functions. > diff --git a/sys/sys/cdefs.h b/sys/sys/cdefs.h > index 9cdc03c861cb..e370f6d6459e 100644 > --- a/sys/sys/cdefs.h > +++ b/sys/sys/cdefs.h > @@ -396,6 +396,14 @@ > #define __unreachable() ((void)0) > #endif > > +#if __has_attribute(optnone) > +#define __no_optimization __attribute__((optnone)) > +#elif __has_attribute(optimize) > +#define __no_optimization __attribute__((optimize(0))) > +#else > +#define __no_optimization > +#endif I think the second one is wrong though: 'optimize' doesn't appear to be a valid clang attribute. GCC uses an optimize("O0") pragma, but it is not an attribute and __has_attribute doesn't work for GCC anyways. AFAICT there is no equivalent declaration in either Darwin or bionic: the rest of the BSDs are still GCC-centric. The location of the declaration is fine, although being a clang-only attribute you could place it later in the header, perhaps just before the nullability attributes. Regards, Pedro. From owner-freebsd-hackers@freebsd.org Mon Jun 5 05:08:00 2017 Return-Path: Delivered-To: freebsd-hackers@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 69892BF6E2A for ; Mon, 5 Jun 2017 05:08:00 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-5.reflexion.net [208.70.210.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1C8C670E9D for ; Mon, 5 Jun 2017 05:07:59 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 8606 invoked from network); 5 Jun 2017 05:07:53 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 5 Jun 2017 05:07:53 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Mon, 05 Jun 2017 01:07:53 -0400 (EDT) Received: (qmail 23400 invoked from network); 5 Jun 2017 05:07:53 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 5 Jun 2017 05:07:53 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 706B8EC805D; Sun, 4 Jun 2017 22:07:52 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: 32-bit powerpc FreeBSD address 0x0-0xff content (physical addresses): What is the explanation? Message-Id: Date: Sun, 4 Jun 2017 22:07:51 -0700 To: Justin Hibbits , Nathan Whitehorn , FreeBSD PowerPC ML , freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 05:08:00 -0000 I've been trying to get evidence for periodic/random panics in the likes of head -r317820 for 32-bit powerpc FreeBSD used on an old PowerMac G5 so-called "Quad Core". One thing that I've noticed that looks odd is that the vmcore.* files (debug.minidump=0) show content that looks like the following for physical address range 0x0..0xff (via a hacked-to-work-a-little kgdb for physical address access to such a vmcore.* file): (kgdb) x/128wx 0x0 0x0: 0x00000000 0x00000000 0x00000000 0x00000000 0x10: 0x00000000 0xffa35e50 0xffa35ee8 0x00000000 0x20: 0x00000000 0x00000000 0x00000000 0x00000000 0x30: 0x00000000 0x00000000 0x00000000 0x00000000 0x40: 0x00000000 0x00000000 0x00000000 0x00000000 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 0x80: 0x00000090 0x7ff7c080 0x7fc9e7c8 0x00000000 0x90: 0x3c007ff7 0x6000c100 0x7c0903a6 0x4e800421 0xa0: 0x00000000 0x00000000 0x00000000 0x00000000 0xb0: 0x00000000 0x00000000 0x00000000 0x00000000 0xc0: 0x00000000 0x00000000 0x00000000 0x00000000 0xd0: 0x00000000 0x00000000 0x00000000 0x00000000 0xe0: 0x00000000 0x00000000 0x00000000 0x00000000 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000 . . . Or viewed as instructions when the bit patterns fit such (with added NOTE's): (kgdb) x/128i 0x0 0x0: .long 0x0 0x4: .long 0x0 0x8: .long 0x0 0xc: .long 0x0 0x10: .long 0x0 0x14: .long 0xffa35e50 0x18: .long 0xffa35ee8 0x1c: .long 0x0 0x20: .long 0x0 0x24: .long 0x0 0x28: .long 0x0 0x2c: .long 0x0 0x30: .long 0x0 0x34: .long 0x0 0x38: .long 0x0 0x3c: .long 0x0 0x40: .long 0x0 0x44: .long 0x0 0x48: .long 0x0 0x4c: .long 0x0 0x50: .long 0x0 0x54: .long 0x0 0x58: .long 0x0 0x5c: .long 0x0 0x60: .long 0x0 0x64: .long 0x0 0x68: .long 0x0 0x6c: .long 0x0 0x70: .long 0x0 0x74: .long 0x0 0x78: .long 0x0 0x7c: .long 0x0 0x80: .long 0x90 0x84: .long 0x7ff7c080 0x88: .long 0x7fc9e7c8 0x8c: .long 0x0 0x90: lis r0,32759 (NOTE: 32759==0x7ff7) 0x94: ori r0,r0,49408 (NOTE: 49408==0xC100) 0x98: mtctr r0 (NOTE: So ctr==r0==0x7ff7C100) 0x9c: bctrl (NOTE: So to 0x7ff7C100 virtual address) 0xa0: .long 0x0 (NOTE: lr would end up pointing here.) 0xa4: .long 0x0 0xa8: .long 0x0 0xac: .long 0x0 0xb0: .long 0x0 0xb4: .long 0x0 0xb8: .long 0x0 0xbc: .long 0x0 0xc0: .long 0x0 0xc4: .long 0x0 0xc8: .long 0x0 0xcc: .long 0x0 0xd0: .long 0x0 0xd4: .long 0x0 0xd8: .long 0x0 0xdc: .long 0x0 0xe0: .long 0x0 0xe4: .long 0x0 0xe8: .long 0x0 0xec: .long 0x0 0xf0: .long 0x0 0xf4: .long 0x0 0xf8: .long 0x0 0xfc: .long 0x0 . . . Is this deliberate? If yes: What is it for? (I've not found what writes those bytes.) I do not make the claim that the above is tied to the periodic/random panics. It just seems unusual. === Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Mon Jun 5 10:03:33 2017 Return-Path: Delivered-To: freebsd-hackers@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 4B044BFAF8D; Mon, 5 Jun 2017 10:03:33 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D924778380; Mon, 5 Jun 2017 10:03:29 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v55A3OQo070099 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 5 Jun 2017 13:03:24 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v55A3OQo070099 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v55A3OCj070098; Mon, 5 Jun 2017 13:03:24 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 5 Jun 2017 13:03:24 +0300 From: Konstantin Belousov To: Eric van Gyzen Cc: FreeBSD Hackers , toolchain@freebsd.org Subject: Re: Function attribute for optimization level Message-ID: <20170605100324.GV82323@kib.kiev.ua> References: <85c47390-dd27-aa74-24fe-25a9a5352527@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <85c47390-dd27-aa74-24fe-25a9a5352527@FreeBSD.org> User-Agent: Mutt/1.8.2 (2017-04-18) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 10:03:33 -0000 I think that toolchain@ is more suitable list for the discussion. On Sun, Jun 04, 2017 at 05:44:31PM -0500, Eric van Gyzen wrote: > _thr_rtld_init() calls memcpy() for the sole purpose of resolving its > PLT entry. With clang 4.0 and the current code, compiler optimization > defeats this attempt by completely eliding the call. Other compilers > or code might emit inline instructions instead of the library call, > also defeating the purpose. After looking more closely at the whole situation, I have a question that we probably must answer first. Is clang -ffreestanding mode broken ? memcpy(3) is not included into the set of the environment features required for a C11 freestanding implementation, and clang pretending that it knows the semantic of the call sounds broken. > > I propose adding "__no_optimization" to sys/cdefs.h. The patch is > below. Empirical testing shows that clang 3.7 and later support > "optnone", and gcc 4.6 and later support "optimize()". Clang 3.4 does > not support either, so it takes the define-to-empty case. I did not > test clang 3.5 or 3.6. Where this attribute should be applied ? To the _thr_rtld_init() function ? > > Side note: GCC 4.6 with optimize(0) on amd64 emits two movq > instructions for memset(x,0,16), but GCC 5 emits a call to memset(). > > I have done no research to see if other popular codebases have such a > definition. If you know of one, please tell me; I would gladly adopt > an already common name for this proposal, for the sake of portability. > > Thanks in advance for your feedback. > > Eric > > > diff --git a/sys/sys/cdefs.h b/sys/sys/cdefs.h index > 9cdc03c861cb..e370f6d6459e 100644 --- a/sys/sys/cdefs.h +++ > b/sys/sys/cdefs.h @@ -396,6 +396,14 @@ #define __unreachable() > ((void)0) #endif > > +#if __has_attribute(optnone) +#define __no_optimization > __attribute__((optnone)) +#elif __has_attribute(optimize) +#define > __no_optimization __attribute__((optimize(0))) +#else +#define > __no_optimization +#endif + /* XXX: should use `#if __STDC_VERSION__ < > 199901'. */ #if !__GNUC_PREREQ__(2, 7) && !defined(__INTEL_COMPILER) > #define __func__ NULL _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Mon Jun 5 06:45:59 2017 Return-Path: Delivered-To: freebsd-hackers@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 6B3A7BF80D2 for ; Mon, 5 Jun 2017 06:45:59 +0000 (UTC) (envelope-from halwe.prateek@gmail.com) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::232]) (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 25913734F8 for ; Mon, 5 Jun 2017 06:45:59 +0000 (UTC) (envelope-from halwe.prateek@gmail.com) Received: by mail-ua0-x232.google.com with SMTP id y4so70747809uay.2 for ; Sun, 04 Jun 2017 23:45:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=1DBtHXMMmkuVh2H0hV9Qg0+OZAk/bV68csPjMNit3Hs=; b=NI2U+B8v6/95AHXIrUYKdIE8NHSgIvl7PQZbxxpQwJVd4PPfEub3TB8ZTwl3drDnBH oGAbAb/Anw2+QrENJRCk6D2MD2CxSt/Vudbgbpq++3GK8kytaWx4iDWXGhHM4O6z6b8Z w14KnFvptzCJQULES9nJa+sV4JDjmnwxOG+XYUknlNapRiJTvKvxNaqh7W6TlPEt7Jkx OnlKXWd3K8EO0AT/qBlz5andWu34cAsatUzGCn085fzdSbpLSjn23iL92PTfYbDvaTNy h1lj+46a78iuZ81uCR7pFIG5XcnBcLS+7zWzQS+Dc9mBSt+1lZefTJb3yprkjWrA0cro /iyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=1DBtHXMMmkuVh2H0hV9Qg0+OZAk/bV68csPjMNit3Hs=; b=W7RH4EXEB7muFLLfzn51aVXSojUg5XBZHrKFMMpT01OXxJKKRembpCEfR68OtgD49V grBIef0MtWRKMsxL3Zhn9Lc7fQPQJjd9tlIkPHBKuQS0ldLozadTzMWw8FB22Jbf5048 94ZaUqlYujdCRvDG/s6cl045qxJB34q5uL5mOQutnrWEKGooxHSh9nWc9EIK79T4/TMI IaVdl7wNMtxJzn5mN+heLvPEBEshwtJPOP5XZwc5nZOBwxT97D8mdROB0kpNy5yRAbA+ kP9ACaQwJMvc3BAIwlnOkIXQ7/KqEljXSqQz3H496g8ce2Ed5dBtA77GUjVVtm2rYOo6 FKbw== X-Gm-Message-State: AODbwcAlyuu3euYmecY7RXdL78lo6X3Qu+/0VK60BzQ/kqC3mf+VMG/Z jUZ8ATp/4dsk8oORhKK93IodbNJCUA== X-Received: by 10.176.0.248 with SMTP id 111mr7003336uaj.133.1496645158106; Sun, 04 Jun 2017 23:45:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.167.141 with HTTP; Sun, 4 Jun 2017 23:45:17 -0700 (PDT) From: Prateek Dilip Halwe Date: Mon, 5 Jun 2017 12:15:17 +0530 Message-ID: Subject: Is mdconfig in FreeBSD and zRAM in linux are same? To: freebsd-hackers@freebsd.org X-Mailman-Approved-At: Mon, 05 Jun 2017 10:44:38 +0000 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 06:45:59 -0000 Hi FreeBSD Hackers, Hope you all are doing good. *Introduction:* I was looking to experiment with my machine by improving its performance by fastening or minimizing the page swapping from the disk. I came across something called as zRAM in Linux, I searched the same for FreeBSD, I came across mdconfig. For more details on zRAM a good link is here . *Question:* My question is, are zRAM and mdconfig doing the same job? Has anyone done some experiments with zRam on FreeBSD, in my case Is it meaningful to consider zram for FreeBSD, given that something like mdconfig is already available in FreeBSD? If so, please share some details and result. Thanks in advance! Thanks & Regards, Prateek Halwe From owner-freebsd-hackers@freebsd.org Mon Jun 5 11:09:17 2017 Return-Path: Delivered-To: freebsd-hackers@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 9D75FBFC415; Mon, 5 Jun 2017 11:09:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4251B79CF9; Mon, 5 Jun 2017 11:09:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v55B9BYn084494 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 5 Jun 2017 14:09:11 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v55B9BYn084494 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v55B9BCN084493; Mon, 5 Jun 2017 14:09:11 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 5 Jun 2017 14:09:11 +0300 From: Konstantin Belousov To: Eric van Gyzen Cc: FreeBSD Hackers , toolchain@freebsd.org Subject: Re: Function attribute for optimization level Message-ID: <20170605110911.GZ82323@kib.kiev.ua> References: <85c47390-dd27-aa74-24fe-25a9a5352527@FreeBSD.org> <20170605100324.GV82323@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170605100324.GV82323@kib.kiev.ua> User-Agent: Mutt/1.8.2 (2017-04-18) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 11:09:17 -0000 On Mon, Jun 05, 2017 at 01:03:24PM +0300, Konstantin Belousov wrote: > I think that toolchain@ is more suitable list for the discussion. > > On Sun, Jun 04, 2017 at 05:44:31PM -0500, Eric van Gyzen wrote: > > _thr_rtld_init() calls memcpy() for the sole purpose of resolving its > > PLT entry. With clang 4.0 and the current code, compiler optimization > > defeats this attempt by completely eliding the call. Other compilers > > or code might emit inline instructions instead of the library call, > > also defeating the purpose. > After looking more closely at the whole situation, I have a question > that we probably must answer first. Is clang -ffreestanding mode > broken ? memcpy(3) is not included into the set of the environment > features required for a C11 freestanding implementation, and clang > pretending that it knows the semantic of the call sounds broken. Ok, I realized that I only added -ffreestanding to the rtld Makefile. So clang is optimizing correctly there. Should we compile both libc and libthr in the freestanding environment as well ? I am sure that there are a lot of similar assumptions that libc and libthr code calls into itself and not into the arbitrary re-implementation of the same code as generated by modern compilers. Then hopefully the __no_optimization hack is not needed. > > > > > I propose adding "__no_optimization" to sys/cdefs.h. The patch is > > below. Empirical testing shows that clang 3.7 and later support > > "optnone", and gcc 4.6 and later support "optimize()". Clang 3.4 does > > not support either, so it takes the define-to-empty case. I did not > > test clang 3.5 or 3.6. > Where this attribute should be applied ? To the _thr_rtld_init() function ? > > > > > Side note: GCC 4.6 with optimize(0) on amd64 emits two movq > > instructions for memset(x,0,16), but GCC 5 emits a call to memset(). > > > > I have done no research to see if other popular codebases have such a > > definition. If you know of one, please tell me; I would gladly adopt > > an already common name for this proposal, for the sake of portability. > > > > Thanks in advance for your feedback. > > > > Eric > > > > > > diff --git a/sys/sys/cdefs.h b/sys/sys/cdefs.h index > > 9cdc03c861cb..e370f6d6459e 100644 --- a/sys/sys/cdefs.h +++ > > b/sys/sys/cdefs.h @@ -396,6 +396,14 @@ #define __unreachable() > > ((void)0) #endif > > > > +#if __has_attribute(optnone) +#define __no_optimization > > __attribute__((optnone)) +#elif __has_attribute(optimize) +#define > > __no_optimization __attribute__((optimize(0))) +#else +#define > > __no_optimization +#endif + /* XXX: should use `#if __STDC_VERSION__ < > > 199901'. */ #if !__GNUC_PREREQ__(2, 7) && !defined(__INTEL_COMPILER) > > #define __func__ NULL _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to > > "freebsd-hackers-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-toolchain@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to "freebsd-toolchain-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Mon Jun 5 11:57:16 2017 Return-Path: Delivered-To: freebsd-hackers@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 29521BFD37D; Mon, 5 Jun 2017 11:57:16 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:470:7a58:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D34DA7B80F; Mon, 5 Jun 2017 11:57:15 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:470:7a58::4075:b535:a8d3:d26] (unknown [IPv6:2001:470:7a58:0:4075:b535:a8d3:d26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 8933919516; Mon, 5 Jun 2017 13:57:13 +0200 (CEST) From: Dimitry Andric Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_C7C66C48-20D1-407B-AAF3-250460E3AE05"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Function attribute for optimization level Date: Mon, 5 Jun 2017 13:57:01 +0200 In-Reply-To: <20170605110911.GZ82323@kib.kiev.ua> Cc: Eric van Gyzen , FreeBSD Hackers , toolchain@freebsd.org To: Konstantin Belousov References: <85c47390-dd27-aa74-24fe-25a9a5352527@FreeBSD.org> <20170605100324.GV82323@kib.kiev.ua> <20170605110911.GZ82323@kib.kiev.ua> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 11:57:16 -0000 --Apple-Mail=_C7C66C48-20D1-407B-AAF3-250460E3AE05 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 5 Jun 2017, at 13:09, Konstantin Belousov wrote: > > On Mon, Jun 05, 2017 at 01:03:24PM +0300, Konstantin Belousov wrote: >> I think that toolchain@ is more suitable list for the discussion. >> >> On Sun, Jun 04, 2017 at 05:44:31PM -0500, Eric van Gyzen wrote: >>> _thr_rtld_init() calls memcpy() for the sole purpose of resolving its >>> PLT entry. With clang 4.0 and the current code, compiler optimization >>> defeats this attempt by completely eliding the call. Other compilers >>> or code might emit inline instructions instead of the library call, >>> also defeating the purpose. >> After looking more closely at the whole situation, I have a question >> that we probably must answer first. Is clang -ffreestanding mode >> broken ? memcpy(3) is not included into the set of the environment >> features required for a C11 freestanding implementation, and clang >> pretending that it knows the semantic of the call sounds broken. > Ok, I realized that I only added -ffreestanding to the rtld Makefile. > So clang is optimizing correctly there. Should we compile both libc > and libthr in the freestanding environment as well ? > > I am sure that there are a lot of similar assumptions that libc and libthr > code calls into itself and not into the arbitrary re-implementation of > the same code as generated by modern compilers. > > Then hopefully the __no_optimization hack is not needed. Like that, or use -fno-builtin: $ cat test-memcpy.c #include void foo(void) { long dummy = -1; memcpy(&dummy, &dummy, sizeof(dummy)); } $ cc -O2 -fno-builtin -fomit-frame-pointer -S test-memcpy.c -o - .text .file "test-memcpy.c" .globl foo # -- Begin function foo .p2align 4, 0x90 .type foo,@function foo: # @foo .cfi_startproc # BB#0: # %entry pushq %rax .Lcfi0: .cfi_def_cfa_offset 16 movq $-1, (%rsp) movq %rsp, %rdi movl $8, %edx movq %rdi, %rsi callq memcpy popq %rax retq .Lfunc_end0: .size foo, .Lfunc_end0-foo .cfi_endproc # -- End function .ident "FreeBSD clang version 5.0.0 (trunk 304659) (based on LLVM 5.0.0svn)" .section ".note.GNU-stack","",@progbits -Dimitry --Apple-Mail=_C7C66C48-20D1-407B-AAF3-250460E3AE05 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.30 iEYEARECAAYFAlk1RxkACgkQsF6jCi4glqMDUwCguMJgKivulhOfFPbolf5dyp4S xXwAoPqPmdS4cIYScjgzYk5BcaONt0X3 =Z2N/ -----END PGP SIGNATURE----- --Apple-Mail=_C7C66C48-20D1-407B-AAF3-250460E3AE05-- From owner-freebsd-hackers@freebsd.org Mon Jun 5 14:14:43 2017 Return-Path: Delivered-To: freebsd-hackers@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 C0C7AAF9F24 for ; Mon, 5 Jun 2017 14:14:43 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from mx1.scaleengine.net (mx1.scaleengine.net [209.51.186.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 98FC07FA7D for ; Mon, 5 Jun 2017 14:14:43 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.2] (unknown [10.1.1.2]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id D98B2130FE for ; Mon, 5 Jun 2017 14:14:35 +0000 (UTC) Subject: Re: Is mdconfig in FreeBSD and zRAM in linux are same? To: freebsd-hackers@freebsd.org References: From: Allan Jude Message-ID: <18f2c9ee-9a7e-d4e4-8e37-1c8d0b2e1e3e@freebsd.org> Date: Mon, 5 Jun 2017 10:14:35 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 14:14:43 -0000 On 2017-06-05 02:45, Prateek Dilip Halwe wrote: > Hi FreeBSD Hackers, > > Hope you all are doing good. > > *Introduction:* > I was looking to experiment with my machine by improving its performance by > fastening or minimizing the page swapping from the disk. > > I came across something called as zRAM > in Linux, I searched the same for FreeBSD, I came across mdconfig. For more > details on zRAM a good link is here > . > > *Question:* > My question is, are zRAM and mdconfig doing the same job? Has anyone done > some experiments with zRam on FreeBSD, in my case Is it meaningful to > consider zram for FreeBSD, given that something like mdconfig is already > available in FreeBSD? If so, please share some details and result. > > Thanks in advance! > > Thanks & Regards, > Prateek Halwe > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > mdconfig creates a memory disk, but it does not perform any compression, so it is not really like zram. With FreeBSD 11.1 and newer, ZFS supports 'compressed ARC', so zvol's you create have their pages cached in ram compressed, but are still backed by disk as well. This is not really the same thing because it provides durability and safety that zram does not. -- Allan Jude From owner-freebsd-hackers@freebsd.org Mon Jun 5 17:02:38 2017 Return-Path: Delivered-To: freebsd-hackers@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 0D0A3AFD402 for ; Mon, 5 Jun 2017 17:02:38 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from nm6.bullet.mail.ne1.yahoo.com (nm6.bullet.mail.ne1.yahoo.com [98.138.90.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D1294261B for ; Mon, 5 Jun 2017 17:02:37 +0000 (UTC) (envelope-from pfg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1496682026; bh=n9g4si0ZIPwrb0Obq8IUihG3DtQg9mz6ILmxX+9kX1I=; h=Subject:From:To:Cc:References:Date:In-Reply-To:From:Subject; b=WW1GpU4iJcJFuvPYO94wbotRGSzireTzFGS0mkf4X7v65n6Dx66YKVS2Fd4U/GTqP9S5nY4IneI3jw37t+cASZYfFn/LeqfAAcXkaIrKPi5WuEVOa2y3VMA1TKQ0ZaIUhkpxgag2rc3/0QbuEX8fGaXAM1/P4KOrmlqV6LEF64B7e6pFVjzf3hWgA8TsKxvCkC+3jBiKA6Pa7xE0EBayHgwl47oPdBNFPhUlTmxm187MZ+uihe/WCS+aCEkXIi+1Bm3xO1xm0hvjq5CC/nF81x/5s7x4n4pcLHAARc+lrbm956vH7YQZWKpy+Jo6xcTd/LednjRGNVgmlQUQo/jStw== Received: from [98.138.100.114] by nm6.bullet.mail.ne1.yahoo.com with NNFMP; 05 Jun 2017 17:00:26 -0000 Received: from [98.138.104.116] by tm105.bullet.mail.ne1.yahoo.com with NNFMP; 05 Jun 2017 17:00:26 -0000 Received: from [127.0.0.1] by smtp225.mail.ne1.yahoo.com with NNFMP; 05 Jun 2017 17:00:26 -0000 X-Yahoo-Newman-Id: 809536.49104.bm@smtp225.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: FQU6C_sVM1kK2_mlEqwmu8Q285YOhvdVnRlZVvB4R424ApY kLop95vis2z64_LgiK5v8gO4hcRT_wIMhCw6njJ1rwOc2pNBKgZbE2YMjMlF qkhjke98layn1b87IeFiSP3Nd346wyHtkMCiDxWPfvA0zu29dTJ3JEnXQK4w UBB3OVhzDwHXtXgl8gtsthwHWABC9LwRjmWJbVt5nbW3JEd9OcDg_TPfgZx2 ffG.59Nr66cOVYnuFzGbhmiirN0qA1FyC3zcsUbRKennK_NEA1vKe9w8XiWV nAjLMiIJZ7jFInVu3bpWaWTEloVIrMlRs7m9RPYMuuVR55D78QlEqlAhgqKq BLIzdCqK2ipd_7i86HGLf3FXe4NusSz2rnEbxQGh2sGbJKZoTAY5wQpqeEst GWJSMeelL.PuWGE.UTJqiX3L80XjEEvv7oCkLrfQ_F9DctXvbsUt5jR5pZij 1ByKyv6GOHNaaYXq0YeHpE.YwmI2Gxt_Lyxqp2prQ1U_5UrLwV1691QDR8ku tz9iXOZ4COYlBRyC9UsY9GxIljzbLwQ3xLiAZqnKfn4Kh X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf Subject: Re: Function attribute for optimization level From: Pedro Giffuni To: Eric van Gyzen Cc: FreeBSD Hackers References: Organization: FreeBSD Project Message-ID: <0e9c89aa-920f-26bb-abde-2f4901740933@FreeBSD.org> Date: Mon, 5 Jun 2017 12:00:26 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 17:02:38 -0000 On 04/06/2017 23:08, Pedro Giffuni wrote: > > Hi Eric; > > It is a good idea : the nonopt attribute is useful in parts of the > boot loader and probably in security-related functions. > > >> diff --git a/sys/sys/cdefs.h b/sys/sys/cdefs.h >> index 9cdc03c861cb..e370f6d6459e 100644 >> --- a/sys/sys/cdefs.h >> +++ b/sys/sys/cdefs.h >> @@ -396,6 +396,14 @@ >> #define __unreachable() ((void)0) >> #endif >> >> +#if __has_attribute(optnone) >> +#define __no_optimization __attribute__((optnone)) >> +#elif __has_attribute(optimize) >> +#define __no_optimization __attribute__((optimize(0))) >> +#else >> +#define __no_optimization >> +#endif > > I think the second one is wrong though: 'optimize' doesn't appear to > be a valid clang attribute. GCC uses an optimize("O0") pragma, but it > is not an attribute and __has_attribute doesn't work for GCC anyways. > Bah, I found it in the GCC 4.4 Release Notes. Fopr GCC you have to check __GNUC_PREREQ__(4, 4) instead __has_attribute(). Cheers, Pedro. From owner-freebsd-hackers@freebsd.org Mon Jun 5 19:57:22 2017 Return-Path: Delivered-To: freebsd-hackers@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 9CC0AB794EF; Mon, 5 Jun 2017 19:57:22 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mailout.stack.nl (mailout05.stack.nl [IPv6:2001:610:1108:5010::202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout.stack.nl", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 67B2867C90; Mon, 5 Jun 2017 19:57:22 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mailout.stack.nl (Postfix) with ESMTP id A4E2D78; Mon, 5 Jun 2017 21:57:19 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id 8D1A228497; Mon, 5 Jun 2017 21:57:19 +0200 (CEST) Date: Mon, 5 Jun 2017 21:57:19 +0200 From: Jilles Tjoelker To: Konstantin Belousov Cc: Eric van Gyzen , FreeBSD Hackers , toolchain@freebsd.org Subject: Re: Function attribute for optimization level Message-ID: <20170605195719.GA46606@stack.nl> References: <85c47390-dd27-aa74-24fe-25a9a5352527@FreeBSD.org> <20170605100324.GV82323@kib.kiev.ua> <20170605110911.GZ82323@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170605110911.GZ82323@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 19:57:22 -0000 On Mon, Jun 05, 2017 at 02:09:11PM +0300, Konstantin Belousov wrote: > On Mon, Jun 05, 2017 at 01:03:24PM +0300, Konstantin Belousov wrote: > > I think that toolchain@ is more suitable list for the discussion. > > On Sun, Jun 04, 2017 at 05:44:31PM -0500, Eric van Gyzen wrote: > > > _thr_rtld_init() calls memcpy() for the sole purpose of resolving its > > > PLT entry. With clang 4.0 and the current code, compiler optimization > > > defeats this attempt by completely eliding the call. Other compilers > > > or code might emit inline instructions instead of the library call, > > > also defeating the purpose. > > After looking more closely at the whole situation, I have a question > > that we probably must answer first. Is clang -ffreestanding mode > > broken ? memcpy(3) is not included into the set of the environment > > features required for a C11 freestanding implementation, and clang > > pretending that it knows the semantic of the call sounds broken. > Ok, I realized that I only added -ffreestanding to the rtld Makefile. > So clang is optimizing correctly there. Should we compile both libc > and libthr in the freestanding environment as well ? > I am sure that there are a lot of similar assumptions that libc and libthr > code calls into itself and not into the arbitrary re-implementation of > the same code as generated by modern compilers. I would prefer using -ffreestanding or -fno-builtin only for the files which need it. For example, builtin memcpy() with a small constant size is useful to read and write data regardless of alignment and type-based aliasing restrictions. If the memcpy() becomes an external call, both code size and speed will be affected and the programmer will probably choose some other way such as unsafe pointer casts or reading one byte at a time. I don't think it is possible to make this completely future-proof, though, since we don't have a lower layer in libc that implements a full C11 hosted environment and a higher layer that contains everything else. > Then hopefully the __no_optimization hack is not needed. Agreed, __no_optimization sounds more like a workaround for bugs in a specific compiler than something with a well-defined meaning across compilers. -- Jilles Tjoelker From owner-freebsd-hackers@freebsd.org Tue Jun 6 08:18:47 2017 Return-Path: Delivered-To: freebsd-hackers@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 2DC97BF9ABB; Tue, 6 Jun 2017 08:18:47 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "theravensnest.org", Issuer "Let's Encrypt Authority X3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 014FC82CDE; Tue, 6 Jun 2017 08:18:46 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from [192.168.1.65] (host81-140-166-137.range81-140.btcentralplus.com [81.140.166.137]) (authenticated bits=0) by theravensnest.org (8.15.2/8.15.2) with ESMTPSA id v568IVnn097686 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 6 Jun 2017 08:18:35 GMT (envelope-from theraven@FreeBSD.org) X-Authentication-Warning: theravensnest.org: Host host81-140-166-137.range81-140.btcentralplus.com [81.140.166.137] claimed to be [192.168.1.65] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Function attribute for optimization level From: David Chisnall In-Reply-To: <20170605195719.GA46606@stack.nl> Date: Tue, 6 Jun 2017 09:18:28 +0100 Cc: Konstantin Belousov , FreeBSD Hackers , Eric van Gyzen , toolchain@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <2C01E322-CD6F-4BE6-B973-5B6C839DA5DE@FreeBSD.org> References: <85c47390-dd27-aa74-24fe-25a9a5352527@FreeBSD.org> <20170605100324.GV82323@kib.kiev.ua> <20170605110911.GZ82323@kib.kiev.ua> <20170605195719.GA46606@stack.nl> To: Jilles Tjoelker X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 08:18:47 -0000 On 5 Jun 2017, at 20:57, Jilles Tjoelker wrote: >=20 > I would prefer using -ffreestanding or -fno-builtin only for the files > which need it. For example, builtin memcpy() with a small constant = size > is useful to read and write data regardless of alignment and = type-based > aliasing restrictions. If the memcpy() becomes an external call, both > code size and speed will be affected and the programmer will probably > choose some other way such as unsafe pointer casts or reading one byte > at a time. In a non-freestanding environment, memcpy, memset, and memcmp calls are = both translated early to LLVM intrinsics and then have special handling = throughout the optimisation pipeline and in code generation. We=E2=80=99r= e likely to pay a noticeable penalty in code size and performance if we = don=E2=80=99t allow the compiler to do these, above and beyond the cost = of the call. David From owner-freebsd-hackers@freebsd.org Tue Jun 6 10:46:22 2017 Return-Path: Delivered-To: freebsd-hackers@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 C3B2EBFCC64 for ; Tue, 6 Jun 2017 10:46:22 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-4.reflexion.net [208.70.210.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6C9AA2DFB for ; Tue, 6 Jun 2017 10:46:21 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 24704 invoked from network); 6 Jun 2017 10:46:20 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 6 Jun 2017 10:46:20 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Tue, 06 Jun 2017 06:46:20 -0400 (EDT) Received: (qmail 29898 invoked from network); 6 Jun 2017 10:46:20 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 6 Jun 2017 10:46:20 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id BB335EC7B76; Tue, 6 Jun 2017 03:46:19 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: A different 32-bit powerpc head -r317820 panic on old PowerMac G5: dual backtraces from "timeout stopping cpus" (dump failed though): any comments? Message-Id: Date: Tue, 6 Jun 2017 03:46:19 -0700 To: Justin Hibbits , Nathan Whitehorn , FreeBSD PowerPC ML , freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 10:46:22 -0000 I'm not sure what to make of this. May be someone has some idea. One of the bt's is for "irq53: smudoorbell0" (tid 100055) the other is = for usb. spinlock 0xefbbf00 (sched lock 1) held by 0x593d6c0 (tid 100055) too = long spinlock 0xxf2e1f8 (sleepq chain) help by 0x17606c0 (tid 100049) too = long timeout stopping cpus usb. . . (I omit any "at kdb_backtrace" lines) 0xe56636d0: at vpanic+0x210 0xe5663740: at panic+0x54 0xe5663790: at _mtx_lock_spin_failed_+0x54 0xe56637b0: at _mtx_lock_spin_cookie+0x19c 0xe5663810: at sched_add+0x140 0xe5663850: at sched_wakeup+0xa4 0xe5663870: at setrunnable+0x9c 0xe5663890: at sleepq_resume_thread+0x17c 0xe56638c0: at sleepq_signal+0xa4 0xe56638f0: at cv_signal+0x94 0xe5663910: at usbd_do_request_callback+0x80 0xe5663930: at usb_request_callback_0x28 0xe5663950: at usbd_callback_wrapper+0xa98 0xe5663990: at usb_command_wrapper+0x14c 0xe56639d0: at usb_callback_proc+0x190 0xe5663a00: at usb_process+0x1d0 0xe5663a50: at fork_exit+0xf4 0xe5663a80: at fork_trampoline+0xc irq53: smudoorbell0. . . 0xe56e4460: at vpanic+0x22c 0xe56e44d0: at panic+0x54 0xe56e4520: at _mtx_lock_spin_failed+0x54 0xe56e4540: at thread_lock_flags_0x1bc 0xe56e45b0: at sleepq_timeout+0x44 0xe56e45f0: at softclock_call_cc+0x1bc 0xe56e4660: at callout_process+0x27c 0xe56e46c0: at handleevents+0x2ac 0xe56e4710: at timercb+0x4c4 0xe56e4790: at decr_intr+0xf0 0xe56e47b0: at powerpc_intrerrupt+0xf4 0xe56e47e0: at kernel DECR trap by _mtx_lock_spin_cookie+0x194 srr1=3D 0x9032 r1=3D 0xe56e48a0 cr=3D 0x20000002 xer=3D 0 ctr=3D 0 0xe56e48a0: at _mtx_lock+_spin_cookie+0x190 0xe56e4900: at sleepq_lock+0xac 0xe56e4930: at wakeup+0x24 0xe56e4950: at smu_doorbell_intr+0x128 0xe56e4980: at intr_event_execute_handler+0x220 0xe56e49f0: at ithread_loop+0xf0 0xe56e4a50: at fork_exit+0xf4 0xe56e4a80: at fork_trampoline+0xc For reference acttrace also reported (that looks odd after the first 2 stack lines): powerpd pid 960 tid 100097 td 0x5ba1999 (CPU 2) 0xd2418510: at uma_zalloc_arg+0x178 0xd2418580: at mmu_unmapdev+desc+0x8 0x00fcf9dc: at primes+0x68 0x00d026b0: at moe64_page_exists_quick+0x1d8 0x00ce0ff8: at mmu_unmapdev_desc+0x8 (CPU3 had an empty backtrace for pid 11's tid 100006.) I had another example of sorts but it did not get far before hanging up: spinlock 0xefbbf00 (sched lock 1) held by 0x146d360 (tid 100004) too = long spinlock 0xefbbf00 (sched lock 1) held by 0x146d360 (tid 100004) too = long (Note: Two different colored lines above but the same otherwise.) timeout stopping cpus Note: The partial backtrace was: ("cpuid =3D 2", all in the first color above) 0xdf6bb5c0: at vpanic+0x210 0xdf6bb630: at panic++0x54 0xdf6bb680: at _mtx_lock_spin_failed+0x54 0xdf6bb6a0: at _mtx_lock_spin_cookie+0x190 0xdf6bb700: at sched_add+0x140 0xdf6bb740: at sched_wakeup+0xa4 0xdf6bb760: at=20 (and that is as far as it got for the backtrace(s)) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Tue Jun 6 18:16:01 2017 Return-Path: Delivered-To: freebsd-hackers@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 24643BF229D for ; Tue, 6 Jun 2017 18:16:01 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-13.reflexion.net [208.70.210.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D209575D28 for ; Tue, 6 Jun 2017 18:15:59 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 29941 invoked from network); 6 Jun 2017 18:09:19 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 6 Jun 2017 18:09:19 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Tue, 06 Jun 2017 14:09:19 -0400 (EDT) Received: (qmail 1220 invoked from network); 6 Jun 2017 18:09:18 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 6 Jun 2017 18:09:18 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 11DB4EC8B8B; Tue, 6 Jun 2017 11:09:18 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: A different 32-bit powerpc head -r317820 panic on old PowerMac G5: dual backtraces from "timeout stopping cpus" (dump failed though): any comments? Date: Tue, 6 Jun 2017 11:09:17 -0700 References: To: Justin Hibbits , Nathan Whitehorn , FreeBSD PowerPC ML , freebsd-hackers@freebsd.org In-Reply-To: Message-Id: <1F1E52BD-375E-47CC-BF06-ECB1092121B4@dsl-only.net> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 18:16:01 -0000 On 2017-Jun-6, at 3:46 AM, Mark Millard wrote: > I'm not sure what to make of this. May be someone has > some idea. >=20 > One of the bt's is for "irq53: smudoorbell0" (tid 100055) the other is = for usb. >=20 > spinlock 0xefbbf00 (sched lock 1) held by 0x593d6c0 (tid 100055) too = long > spinlock 0xxf2e1f8 (sleepq chain) help by 0x17606c0 (tid 100049) too = long > timeout stopping cpus >=20 > usb. . . > (I omit any "at kdb_backtrace" lines) >=20 > 0xe56636d0: at vpanic+0x210 > 0xe5663740: at panic+0x54 > 0xe5663790: at _mtx_lock_spin_failed_+0x54 > 0xe56637b0: at _mtx_lock_spin_cookie+0x19c > 0xe5663810: at sched_add+0x140 > 0xe5663850: at sched_wakeup+0xa4 > 0xe5663870: at setrunnable+0x9c > 0xe5663890: at sleepq_resume_thread+0x17c > 0xe56638c0: at sleepq_signal+0xa4 > 0xe56638f0: at cv_signal+0x94 > 0xe5663910: at usbd_do_request_callback+0x80 > 0xe5663930: at usb_request_callback_0x28 > 0xe5663950: at usbd_callback_wrapper+0xa98 > 0xe5663990: at usb_command_wrapper+0x14c > 0xe56639d0: at usb_callback_proc+0x190 > 0xe5663a00: at usb_process+0x1d0 > 0xe5663a50: at fork_exit+0xf4 > 0xe5663a80: at fork_trampoline+0xc >=20 > irq53: smudoorbell0. . . >=20 > 0xe56e4460: at vpanic+0x22c > 0xe56e44d0: at panic+0x54 > 0xe56e4520: at _mtx_lock_spin_failed+0x54 > 0xe56e4540: at thread_lock_flags_0x1bc > 0xe56e45b0: at sleepq_timeout+0x44 > 0xe56e45f0: at softclock_call_cc+0x1bc > 0xe56e4660: at callout_process+0x27c > 0xe56e46c0: at handleevents+0x2ac > 0xe56e4710: at timercb+0x4c4 > 0xe56e4790: at decr_intr+0xf0 > 0xe56e47b0: at powerpc_intrerrupt+0xf4 > 0xe56e47e0: at kernel DECR trap > by _mtx_lock_spin_cookie+0x194 > srr1=3D 0x9032 > r1=3D 0xe56e48a0 > cr=3D 0x20000002 > xer=3D 0 > ctr=3D 0 > 0xe56e48a0: at _mtx_lock+_spin_cookie+0x190 > 0xe56e4900: at sleepq_lock+0xac > 0xe56e4930: at wakeup+0x24 > 0xe56e4950: at smu_doorbell_intr+0x128 > 0xe56e4980: at intr_event_execute_handler+0x220 > 0xe56e49f0: at ithread_loop+0xf0 > 0xe56e4a50: at fork_exit+0xf4 > 0xe56e4a80: at fork_trampoline+0xc >=20 > For reference acttrace also reported > (that looks odd after the first 2 > stack lines): >=20 > powerpd pid 960 tid 100097 td 0x5ba1999 (CPU 2) > 0xd2418510: at uma_zalloc_arg+0x178 > 0xd2418580: at mmu_unmapdev+desc+0x8 > 0x00fcf9dc: at primes+0x68 > 0x00d026b0: at moe64_page_exists_quick+0x1d8 > 0x00ce0ff8: at mmu_unmapdev_desc+0x8 >=20 > (CPU3 had an empty backtrace for pid 11's > tid 100006.) >=20 >=20 > I had another example of sorts but it did not > get far before hanging up: >=20 > spinlock 0xefbbf00 (sched lock 1) held by 0x146d360 (tid 100004) too = long > spinlock 0xefbbf00 (sched lock 1) held by 0x146d360 (tid 100004) too = long >=20 > (Note: Two different colored lines above but the > same otherwise.) >=20 > timeout stopping cpus >=20 > Note: The partial backtrace was: > ("cpuid =3D 2", all in the first color above) >=20 > 0xdf6bb5c0: at vpanic+0x210 > 0xdf6bb630: at panic++0x54 > 0xdf6bb680: at _mtx_lock_spin_failed+0x54 > 0xdf6bb6a0: at _mtx_lock_spin_cookie+0x190 > 0xdf6bb700: at sched_add+0x140 > 0xdf6bb740: at sched_wakeup+0xa4 > 0xdf6bb760: at=20 >=20 > (and that is as far as it got for the backtrace(s)) FYI: I'm currently doing an approximate binary search for localizing part of the panic problem. This is based on the classic panics that are instead from jumping to a non-code area. . . At a given point in my other experiments I was getting: srr0=3D0x90a0f0 etext+0xb8fc Adding (unused) code somewhat before that etext (so increasing etext) got: srr0=3D0x90a0f0 etext+0xb8a8 (The additional code was larger than I now use.) But instead adding some code earlier (by around 0x100000 in this example) got: srr0=3D0x90a110 etext+0xb8fc So comparing to the starting conditions in each case: The bad-address accessed in one case stayed constant but the etext offset decreased: in essence the only thing that happened is etext increased (matching the offset decrease). In the other case the etext offset stayed constant but the bad-address and etext increased by the same amount. Unfortunately this will take a while: A) It typically takes hours for a failure to happen, I've had up to between 7 hours and 8 hours. (I've had minutes-to-failure but it is rare.) B) I'd let it go 24 hours before concluding that a test combination was not likely to produce an obvious form of failure (such as the panic). (I've had (B) in some earlier forms of testing variations of things.) Another time-taker is that I need to be around because I avoid leaving the PowerMac G5 panicked with the fans going fill-speed for long periods. Currently I'm adding code by adding: void HACKISH_EXTRA_CODE(void) {} to one .c file from /usr/src/sys/. . . based which file gets to within a ballpark of a more accurate binary search position. (Large binary search jumps currently: I'm not being picky about where in the .c the addition is made yet.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Wed Jun 7 04:49:45 2017 Return-Path: Delivered-To: freebsd-hackers@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 B2453BFB24A for ; Wed, 7 Jun 2017 04:49:45 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-12.reflexion.net [208.70.210.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7768411AD for ; Wed, 7 Jun 2017 04:49:44 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 18924 invoked from network); 7 Jun 2017 04:49:43 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 7 Jun 2017 04:49:43 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Wed, 07 Jun 2017 00:49:43 -0400 (EDT) Received: (qmail 5344 invoked from network); 7 Jun 2017 04:49:43 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 7 Jun 2017 04:49:43 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id AC81FEC7A6F; Tue, 6 Jun 2017 21:49:42 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: 32-bit powerpc FreeBSD head -r317820 panic example: Example showing register r10 having been trashed during set_affinity's time frame Message-Id: <1738C902-7A9C-4711-A2F7-D302249C9AF8@dsl-only.net> Date: Tue, 6 Jun 2017 21:49:42 -0700 To: Justin Hibbits , Nathan Whitehorn , FreeBSD PowerPC ML , freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 04:49:45 -0000 Summary of the analysis below: Something trashed the r10 value during set_affinity, effectively replacing a struct td_sched * value with what happened to be a struct thread * value. That in turn lead to what should have been a cpuid (for one of 4 CPUs) to instead be a struct td_sched * value. And that in turn lead to a data storage interrupt from the indexing into cpuid_to_pcpu being way out of bounds. Context: 32-bit powerpc head -r317820 used on a old PowerMac G5 so-called "Quad Core". The analysis from a panic's dump and from pictures of ddb output and using the kernel debug file. . . I got a panic that it looked like I could back calculate a ways to see what was odd somewhat earlier. This is that back calculation sequence. This will start in ipi_cpu where the panic occurred and progress backwards into sched_affinity. void ipi_cpu(int cpu, u_int ipi) { ipi_send(cpuid_to_pcpu[cpu], ipi); } was: (kgdb) x/90i ipi_cpu 0x8eb0dc : stwu r1,-32(r1) 0x8eb0e0 : mflr r0 0x8eb0e4 : stw r30,24(r1) 0x8eb0e8 : stw r31,28(r1) 0x8eb0ec : stw r0,36(r1) 0x8eb0f0 : mr r31,r1 0x8eb0f4 : bcl- 20,4*cr7+so,0x8eb0f8 0x8eb0f8 : mflr r30 0x8eb0fc : lwz r0,-32(r30) 0x8eb100 : add r30,r0,r30 0x8eb104 : rlwinm r3,r3,2,0,29 0x8eb108 : lwz r9,-32756(r30) 0x8eb10c : lwzx r3,r3,r9 0x8eb110 : bl 0x8eb018 0x8eb114 : lwz r11,0(r1) 0x8eb118 : lwz r0,4(r11) 0x8eb11c : mtlr r0 0x8eb120 : lwz r30,-8(r11) 0x8eb124 : lwz r31,-4(r11) 0x8eb128 : mr r1,r11 0x8eb12c : blr 0x8eb130 : .long 0x43ce40 The point of failure (srr0 value) is: 0x8eb10c : lwzx r3,r3,r9 (Note: This is a form of r3:=3DMEM(r3+r9,4). Luckily r3 was not updated because of the bad r3+r9 value.) Note that the only prior instruction modifying r3 in ipi_cpu is: 0x8eb104 : rlwinm r3,r3,2,0,29 The "show reg r3" result was: 0x51f2880. So prior to the shift by 2 and masking off of the least significant 2 bits its value was: r3=3D0x147CA20 I will note that the 0x51f2880 + the "show reg r9" value 0xf2c9fc (i.e., &cpuid_to_pcpu) produces: 0x611f27c -- and the exception was reported as being for virtual address 0x611f27c . By the source code structure r3 was supposed to be one of the values: 0x0, 0x1, 0x2 or 0x3 instead. (The PowerMac G5 "Quad Core" has 4 cpus.) With the "show reg r4" result being 0x1 it means that the call to ipi_cpu was apparently (by values passed): ipi_cpu(0x147CA20, 0x1) "Show allpcpu" reported that cpuid=3D3 had: curthread =3D 0x147ca20: pid 11 tid 100006 "idle: cpu3" idlethread =3D 0x147ca20: did 100006 "idle: cpu3" where 0x147d000 (for cpuid 2) has 0x147d008 holding a 0x147ca20 value. So somehow a thread address for cpuid 3 was given to ipi_cpu instead of 0x3 . The backtrace shows that the caller of ipi_cpu was sched_affinity: void sched_affinity(struct thread *td) { #ifdef SMP struct td_sched *ts; THREAD_LOCK_ASSERT(td, MA_OWNED); ts =3D td_get_sched(td); if (THREAD_CAN_SCHED(td, ts->ts_cpu)) return; if (TD_ON_RUNQ(td)) { sched_rem(td); sched_add(td, SRQ_BORING); return; } if (!TD_IS_RUNNING(td)) return; /* * Force a switch before returning to userspace. If the * target thread is not running locally send an ipi to force * the issue. */ td->td_flags |=3D TDF_NEEDRESCHED; if (td !=3D curthread) ipi_cpu(ts->ts_cpu, IPI_PREEMPT); #endif } So the implication is that ts->ts_cpu had the value 0x147ca20 instead of the value 3 at the time of the call sequence. sched_affinity was: 0x535ab8 : stwu r1,-32(r1) 0x535abc : mflr r0 0x535ac0 : stw r29,20(r1) 0x535ac4 : stw r30,24(r1) 0x535ac8 : stw r31,28(r1) 0x535acc : stw r0,36(r1) 0x535ad0 : mr r31,r1 0x535ad4 : mr r29,r3 0x535ad8 : lwz r0,0(r3) 0x535adc : addi r10,r3,808 0x535ae0 : lwz r9,8(r10) 0x535ae4 : lwz r11,48(r3) 0x535ae8 : rlwinm r0,r9,29,3,29 0x535aec : clrlwi r9,r9,27 0x535af0 : lwzx r0,r11,r0 0x535af4 : sraw r0,r0,r9 0x535af8 : andi. r9,r0,1 0x535afc : bne- 0x535b4c 0x535b00 : lwz r0,652(r3) 0x535b04 : cmpwi cr7,r0,3 0x535b08 : bne+ cr7,0x535b20 = 0x535b0c : bl 0x5341c0 0x535b10 : mr r3,r29 0x535b14 : li r4,0 0x535b18 : bl 0x53583c 0x535b1c : b 0x535b4c 0x535b20 : cmpwi cr7,r0,4 0x535b24 : bne- cr7,0x535b4c = 0x535b28 : lwz r0,156(r3) 0x535b2c : oris r0,r0,1 0x535b30 : stw r0,156(r3) 0x535b34 : mr r0,r2 0x535b38 : cmpw cr7,r3,r0 0x535b3c : beq- cr7,0x535b4c = 0x535b40 : lwz r3,8(r10) 0x535b44 : li r4,1 0x535b48 : bl 0x8eb0dc 0x535b4c : lwz r11,0(r1) 0x535b50 : lwz r0,4(r11) 0x535b54 : mtlr r0 0x535b58 : lwz r29,-12(r11) 0x535b5c : lwz r30,-8(r11) 0x535b60 : lwz r31,-4(r11) 0x535b64 : mr r1,r11 0x535b68 : blr 0x535b6c : .long 0x7e7f18 The only call executed by sched_affinity was to ipi_cpu given what is inlined and the fact that it made it to do the ipi_cpu bl instruction. Since ipi_cpu leaves various registers alone some register values from sched_affinity were preserved for "show reg" use. r10 is an example in: 0x535ad4 : mr r29,r3 . . . 0x535adc : addi r10,r3,808 . . . 0x535b40 : lwz r3,8(r10) 0x535b44 : li r4,1 0x535b48 : bl 0x8eb0dc (r29 is another register value that is preserved in what sched_affinity called. r29 reports what r3 was when sched_affinity was called: 0x147d000, which makes sense. Also 808 is in decimal notation.) That sched_affinity code corresponds to (r10 for ts below): sched_affinity(struct thread *td) . . . struct td_sched *ts; . . . ts =3D td_get_sched(td); . . . ipi_cpu(ts->ts_cpu, IPI_PREEMPT); where "show reg r10" reported: 0x147d000, which matched the "show allpcpu" for cpuid=3D2: curthread =3D 0x147d000: pid11 tid 100005 "idle: cpu2" But it should not match that. . . r10 should have been 0x147d328 (0x147d00+0x328) but is reported as 0x147d000 and the behavior reported for ipi_cpu agrees with 0x147d000: 8(r10) then extracts a 0x0147ca20 value from 0x147d008 instead of a 0x0 from 0x147d328 . So something trashed r10 before: 0x535b40 : lwz r3,8(r10) and so effectively replaced ts with the td value. Trashing r3 so that r3+808=3D=3D0x147d000 when 0x535adc executes seems unlikely but is a technical possibility for how r10 ends up trashed. Other notes: Some of the details not shown above are: static __inline __pure2 struct td_sched * td_get_sched(struct thread *td) { =20 return ((struct td_sched *)&td[1]); } and: /* * Thread scheduler specific section. All fields are protected * by the thread lock. */ struct td_sched { struct runq *ts_runq; /* Run-queue we're queued on. */ short ts_flags; /* TSF_* flags. */ int ts_cpu; /* CPU that we have affinity = for. */ int ts_rltick; /* Real last tick, for affinity. = */ int ts_slice; /* Ticks of slice remaining. */ u_int ts_slptime; /* Number of ticks we vol. slept = */ u_int ts_runtime; /* Number of ticks we were = running */ int ts_ltick; /* Last tick that we were = running on */ int ts_ftick; /* First tick that we were = running on */ int ts_ticks; /* Tick count */ #ifdef KTR char ts_name[TS_NAME_LEN]; #endif }; where td_sched is a suffix after a "struct thread", such as the space reserved in: struct thread0_storage { struct thread t0st_thread; uint64_t t0st_sched[10]; }; and checked by: _Static_assert(sizeof(struct thread) + sizeof(struct td_sched) <=3D sizeof(struct thread0_storage), "increase struct thread0_storage.t0st_sched size"); =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Wed Jun 7 18:34:48 2017 Return-Path: Delivered-To: freebsd-hackers@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 B3ED9D76813 for ; Wed, 7 Jun 2017 18:34:48 +0000 (UTC) (envelope-from tyler@tysdomain.com) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (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 73DB37E161 for ; Wed, 7 Jun 2017 18:34:48 +0000 (UTC) (envelope-from tyler@tysdomain.com) Received: by mail-qt0-x231.google.com with SMTP id u19so16197622qta.3 for ; Wed, 07 Jun 2017 11:34:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tysdomain-com.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=FLbOWxOLpLkNlq1qlilqGjQaHH9TeNalAllm+NwzWYE=; b=iOisNd/+zSzfDriLhYlGqdT4+UFAFKBSPzn1qjv6W3OxYjDps+BFzuzHqlnjfeHT4M emvjb7k7L4nV7TDP45HaxQFh8lrJCftYJLsL81nl9nuKFlylQXVze7oSW28SY1eQSB0c OMzvUPQ9EkDgTjWXK9nRGHidh4uDqbdOCxefizn/o8MZ98RtV8LnCzbApK9YBCQZOHQQ bqAut79uz2dFhkyC4gXun56FipX893yoLgO4heTtUUs8TfUFSpLXXPXZ3VaXVyooQy6X CZUvrCDDR1qQe8EQluPYLYPSKZyQdzBoZoJCiMcwHPqTeiDB2GcgEFz61HuMzENVjy5o a+Zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=FLbOWxOLpLkNlq1qlilqGjQaHH9TeNalAllm+NwzWYE=; b=U/poS8VDXXF3tWa5ixQtClal0b5E2a0BuQe4FvIrT8LRLB34T7YfMFhAjt4LUEnd1D GS1hsfN4arnbIbAqgjmSBEes2Q0SER34NBvloxeTGaVlg1mzQuxuvTdtv23DG2Zapszn 7kOPyU0OdiuKlnjQHAVLE6HmerykftGN3yvzW98eNes1ry6gSQfiADdd564rRBU8q5cw NN16ukuV5feYszztyqkm8gbqBa1mnQtCH02vBXd//vU6dAe5QyRfJZcT6EJys/YFEV7h rRRlIy2kI4MWq/HNDDnAJpoTgYEs9EIcwzlv9vuerEdrGh2KHZBnh6PSbGCkAaUwIzN3 B1vw== X-Gm-Message-State: AODbwcC+dOZk7VDo4LdheziU4pt5CZu3IQOFF8V8Aa9FoAlKQ8lO6q6U MkGjYQDrN4xl961x9oAFUA== X-Received: by 10.200.45.231 with SMTP id q36mr10574593qta.177.1496860487244; Wed, 07 Jun 2017 11:34:47 -0700 (PDT) Received: from [10.201.1.53] ([69.43.66.10]) by smtp.gmail.com with ESMTPSA id w81sm1726891qkg.23.2017.06.07.11.34.46 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Jun 2017 11:34:46 -0700 (PDT) To: freebsd-hackers@freebsd.org From: "Littlefield, Tyler" Subject: RAND_MAX is power of 2 Message-ID: <9efa6e4a-3166-58a8-99a3-02e920366f39@tysdomain.com> Date: Wed, 7 Jun 2017 14:34:48 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 18:34:48 -0000 All: I'm trying to find another solution to this and port this server to FreeBSD. So far the only thing holding me up is that they want RAND_MAX to be a power of 2, and I don't want to just change things without knowing what I'm changing. Is there a reason for this? The code is here: https://pastebin.com/yeha7C8Y Thanks, From owner-freebsd-hackers@freebsd.org Wed Jun 7 19:00:23 2017 Return-Path: Delivered-To: freebsd-hackers@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 1B4B4D76FEB for ; Wed, 7 Jun 2017 19:00:23 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 01BCF7EAFE for ; Wed, 7 Jun 2017 19:00:22 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id v57J0FQm006267 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 7 Jun 2017 12:00:15 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id v57J0FE2006266; Wed, 7 Jun 2017 12:00:15 -0700 (PDT) (envelope-from sgk) Date: Wed, 7 Jun 2017 12:00:15 -0700 From: Steve Kargl To: "Littlefield, Tyler" Cc: freebsd-hackers@freebsd.org Subject: Re: RAND_MAX is power of 2 Message-ID: <20170607190015.GA6134@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <9efa6e4a-3166-58a8-99a3-02e920366f39@tysdomain.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9efa6e4a-3166-58a8-99a3-02e920366f39@tysdomain.com> User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 19:00:23 -0000 On Wed, Jun 07, 2017 at 02:34:48PM -0400, Littlefield, Tyler wrote: > All: > > I'm trying to find another solution to this and port this server to > FreeBSD. So far the only thing holding me up is that they want RAND_MAX > to be a power of 2, and I don't want to just change things without > knowing what I'm changing. Is there a reason for this? svn log -r 252608 /usr/src/include/stdlib.h r252608 | ache | 2013-07-03 14:21:54 -0700 (Wed, 03 Jul 2013) | 15 lines 1) POSIX requires rand(3) return values to be in the [0, RAND_MAX] range, but ACM formula we use have internal state (and return value) in the [1, 0x7ffffffe] range, so our RAND_MAX (0x7fffffff) is never reached because it is off by one, zero is not reached too. Correct both RAND_MAX and rand(3) return value, shifting last one to the 0 by 1 subtracted, resulting POSIXed [0, 0x7ffffffd(=new RAND_MAX)] range. 2) Add a checks for not overflowing on too big seeds. It may happens on the machines, where sizeof(unsigned int) > 32 bits. Reviewed by: bde [1] MFC after: 2 weeks -- Steve 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 20161221 https://www.youtube.com/watch?v=IbCHE-hONow From owner-freebsd-hackers@freebsd.org Wed Jun 7 23:33:38 2017 Return-Path: Delivered-To: freebsd-hackers@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 7178FD7F3E8; Wed, 7 Jun 2017 23:33:38 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 043423291; Wed, 7 Jun 2017 23:33:37 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 1209190c-afdff70000001600-ed-59388d485873 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 87.0E.05632.84D88395; Wed, 7 Jun 2017 19:33:29 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id v57NXRUF004009; Wed, 7 Jun 2017 19:33:28 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v57NXOud010771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 7 Jun 2017 19:33:26 -0400 Date: Wed, 7 Jun 2017 18:33:24 -0500 From: Benjamin Kaduk To: freebsd-hackers@FreeBSD.org Cc: freebsd-current@FreeBSD.org Subject: Call for 2017Q2 Quarterly Status Reports Message-ID: <20170607233323.GZ39245@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="3eH4Qcq5fItR5cpy" Content-Disposition: inline User-Agent: Mutt/1.7.1 (2016-10-04) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDIsWRmVeSWpSXmKPExsUixCmqrOvZaxFpsPevgcWcNx+YLLZv/sfo wOQx49N8lgDGKC6blNSczLLUIn27BK6Ma0u9C/4LVjTOaGNvYLzA38XIySEhYCJxpvcHYxcj F4eQwGImiYWfHjBBOBsYJZY93MYC4VxhkrjUsYoFpIVFQEVi6vYFYDabgJrE+hXXmEFsEQF5 iX1N79lBbGYg+9fWJjBbWMBQYvqCjWA2L9C663u2QtmCEidnPmGBqC+TOP/yNFsXIweQLS2x /B8HSFhUQFni7+F7LBMY+WYh6ZiFpGMWQgdEWEvixr+XTBjCthLr1r1nWcDItopRNiW3Sjc3 MTOnODVZtzg5MS8vtUjXUC83s0QvNaV0EyM4YCV5djCeeeN1iFGAg1GJhzdAziJSiDWxrLgy 9xCjJAeTkihvhSdQiC8pP6UyI7E4I76oNCe1+BCjCtCuRxtWX2CUYsnLz0tVEuGd3QRUx5uS WFmVWpQPUybNwaIkziuh0RghJJCeWJKanZpakFoEk5Xh4FCS4LXpAWoULEpNT61Iy8wpQUgz cXAeYpTg4AEa/qMOZHhxQWJucWY6RP4Uo6KUOK8BSLMASCKjNA+uF5RoJLL317xiFAd6S5iX AaSKB5ik4LpfAQ1mAhrMd8kEZHBJIkJKqoEx8rKjzqzo3umpq7lve7hb7A33vTnzfmu8ZISU t8iUno63iWIVt/pVmJbNcDucK9TyKYp7Rl/Jh0cmJTL833J6F/7ida6vlNkZycG33025sf6I uLr8H88v33e89cv7NmWq5ZQj8QEcbiIHTnLsuHoqlMOIYVlioOtMhrTHbZ1vpu598OB40ikl luKMREMt5qLiRACokFRpDwMAAA== X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 23:33:38 -0000 --3eH4Qcq5fItR5cpy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Dear FreeBSD Community, The deadline for the next FreeBSD Quarterly Status update is July 7, 2017, for work done in April through June. Status report submissions do not need to be very long. They may be about anything happening in the FreeBSD project and community, and provide a great way to inform FreeBSD users and developers about work that is underway and completed. Submission of reports is not restricted to committers; anyone doing anything interesting and FreeBSD related can -- and should -- write one! The preferred and easiest submission method is to use the XML generator [1] with the results emailed to the status report team at monthly@FreeBSD.org . (Do be sure, though, to save the form output and not the form itself!) There is also an XML template [2] that can be filled out manually and attached if preferred. For the expected content and style, please study our guidelines on how to write a good status report [3]. You can also review previous issues [4][5] for ideas on the style and format. We look forward to seeing your 2017Q2 reports! Thanks, Ben (on behalf of monthly@) [1] https://www.FreeBSD.org/cgi/monthly.cgi [2] https://www.FreeBSD.org/news/status/report-sample.xml [3] https://www.FreeBSD.org/news/status/howto.html [4] https://www.FreeBSD.org/news/status/report-2016-10-2016-12.html [5] https://www.FreeBSD.org/news/status/report-2017-01-2017-03.html --3eH4Qcq5fItR5cpy Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQGgBAABCgAGBQJZOI00AAoJECjZpvNk63USKBwMIKJS/VEY3Eh18tFggVc8+rHQ NE7Z+nMUfMokRM9eiBnHTODfVsUMoyycD5z8HTTQaSKEmH5W5knzMz6hk5VpvV1P fObTMuxounYJ8nLb5DyhWRJJSg2qMYw+OY9cr2f9zVBjo3hg/0V4J+tuMAd7qr1r RReHfErfee5cv5GYY1eg0QW37wkBCsn96+q7wU3Vuin+BjK9Xt70EfMTvOlzx2p3 fyO4xbQjXqYvHJI33ewda2n7FzvyPuKekr71e2zkLYhSEt0JI9sV8sp3mO2BeK8z kDjAmexdJpucd3eJRfNj7dSvTdG2spQlXV4l/VFJ04a362gkQ7pNhiHQYPaFlCL7 OFf598FWzepoQUZMKRiJLdqWd32tRtFmbprw/idhiu/kb18LSvyj6zUnUSsTIjgA 7T3EbeXOe5bUqWIAMS/9GBkqmqBs6x0yi8057FWbljq8nJflk8QJdqbTCTLDRoDl DlOurghfTpFZRlSbrchgAAwBDVhQzAjZznFMr/6j9QvLR5U= =rleg -----END PGP SIGNATURE----- --3eH4Qcq5fItR5cpy-- From owner-freebsd-hackers@freebsd.org Thu Jun 8 12:22:48 2017 Return-Path: Delivered-To: freebsd-hackers@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 DAFDABFDF21 for ; Thu, 8 Jun 2017 12:22:48 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from dedi548.your-server.de (dedi548.your-server.de [85.10.215.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9523E7FE6D; Thu, 8 Jun 2017 12:22:48 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from [78.47.166.52] (helo=sslproxy04.your-server.de) by dedi548.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85_2) (envelope-from ) id 1dIw2k-00031U-2t; Thu, 08 Jun 2017 13:56:02 +0200 Received: from [82.135.62.35] (helo=mail.embedded-brains.de) by sslproxy04.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dIw2j-0000lY-QZ; Thu, 08 Jun 2017 13:56:01 +0200 Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 0B6932A004F; Thu, 8 Jun 2017 13:56:04 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id T6ks418pt9iK; Thu, 8 Jun 2017 13:56:03 +0200 (CEST) Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 80E052A092A; Thu, 8 Jun 2017 13:56:03 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id s2nR3lSLv3ZL; Thu, 8 Jun 2017 13:56:03 +0200 (CEST) Received: from [192.168.96.129] (unknown [192.168.96.129]) by mail.embedded-brains.de (Postfix) with ESMTPSA id 69F2E2A004F; Thu, 8 Jun 2017 13:56:03 +0200 (CEST) Subject: Re: Function attribute for optimization level To: FreeBSD References: <85c47390-dd27-aa74-24fe-25a9a5352527@FreeBSD.org> Cc: Eric van Gyzen From: Sebastian Huber Message-ID: Date: Thu, 8 Jun 2017 13:55:59 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <85c47390-dd27-aa74-24fe-25a9a5352527@FreeBSD.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: quoted-printable X-Authenticated-Sender: smtp-embedded@poldinet.de X-Virus-Scanned: Clear (ClamAV 0.99.2/23454/Thu Jun 8 06:37:49 2017) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 12:22:49 -0000 As far as I know this attribute is broken in GCC, see also: https://gcc.gnu.org/ml/gcc/2012-07/msg00201.html I would rather use the -fno-builtin-memcpy option. --=20 Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.huber@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine gesch=C3=A4ftliche Mitteilung im Sinne des EHUG= . From owner-freebsd-hackers@freebsd.org Sat Jun 10 16:26:04 2017 Return-Path: Delivered-To: freebsd-hackers@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 40693BF124C for ; Sat, 10 Jun 2017 16:26:04 +0000 (UTC) (envelope-from Aaron.Caza@ca.weatherford.com) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0053.outbound.protection.outlook.com [104.47.40.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B6E637E710 for ; Sat, 10 Jun 2017 16:26:03 +0000 (UTC) (envelope-from Aaron.Caza@ca.weatherford.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=weatherford.onmicrosoft.com; s=selector1-ca-weatherford-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xi15YLjR1z3RmUovYpnpoFIEKzgaL7X2jik8wPtzRWc=; b=Z6ybsmzdHgNVDmnQoo7yV/qT0MA7NsjKgSlyUOtm+GEcft1YHrcNWUwzErUzPL5QaO3FU0LbQv+i2FqFDRvRhAvzjK+RxtUb+C5o8ibvKcFkGumfVBQAeDh3XyZHPck3Rg//QvTTSuySJklmrbDj3Sw/mlX9rIolwTlsdLVkV8M= Received: from CY1PR03CA0031.namprd03.prod.outlook.com (10.174.128.41) by BN6PR03MB3089.namprd03.prod.outlook.com (10.174.94.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1157.12; Sat, 10 Jun 2017 16:26:01 +0000 Received: from BN1BFFO11FD045.protection.gbl (2a01:111:f400:7c10::1:114) by CY1PR03CA0031.outlook.office365.com (2603:10b6:600::41) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1157.12 via Frontend Transport; Sat, 10 Jun 2017 16:26:01 +0000 Authentication-Results: spf=pass (sender IP is 23.103.226.20) smtp.mailfrom=ca.weatherford.com; freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=bestguesspass action=none header.from=ca.weatherford.com; Received-SPF: Pass (protection.outlook.com: domain of ca.weatherford.com designates 23.103.226.20 as permitted sender) receiver=protection.outlook.com; client-ip=23.103.226.20; helo=032-smtp-out.weatherford.com; Received: from 032-smtp-out.weatherford.com (23.103.226.20) by BN1BFFO11FD045.mail.protection.outlook.com (10.58.145.0) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1143.11 via Frontend Transport; Sat, 10 Jun 2017 16:26:00 +0000 Received: from DM2PR58MB013.032d.mgd.msft.net (141.251.110.81) by DM2PR58MB015.032d.mgd.msft.net (141.251.110.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1143.10; Sat, 10 Jun 2017 16:25:59 +0000 Received: from DM2PR58MB013.032d.mgd.msft.net ([141.251.110.81]) by DM2PR58MB013.032d.mgd.msft.net ([141.251.110.81]) with mapi id 15.01.1143.022; Sat, 10 Jun 2017 16:25:59 +0000 From: "Caza, Aaron" To: "freebsd-hackers@freebsd.org" Subject: FreeBSD10 Stable + ZFS + PostgreSQL + SSD performance drop < 24 hours Thread-Topic: FreeBSD10 Stable + ZFS + PostgreSQL + SSD performance drop < 24 hours Thread-Index: AdLiAalX9ncyh3crQla1B5/716RidA== Date: Sat, 10 Jun 2017 16:25:59 +0000 Message-ID: <79528bf7a85a47079756dc508130360b@DM2PR58MB013.032d.mgd.msft.net> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [141.251.136.132] x-ms-publictraffictype: Email X-MS-TrafficTypeDiagnostic: DM2PR58MB015:|BN6PR03MB3089: X-MS-Office365-Filtering-Correlation-Id: ccdb28f1-9daf-4912-2cf9-08d4b01d61b9 MIME-Version: 1.0 X-OrganizationHeadersPreserved: DM2PR58MB015.032d.mgd.msft.net X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:23.103.226.20; IPV:NLI; CTRY:; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(39840400002)(39860400002)(39410400002)(39400400002)(39450400003)(39850400002)(2980300002)(438002)(199003)(189002)(9170700003)(3846002)(790700001)(5890100001)(102836003)(22756006)(108616004)(5660300001)(50986999)(5640700003)(24736003)(72206003)(8936002)(478600001)(8676002)(81166006)(2501003)(7736002)(54356999)(66066001)(356003)(38730400002)(6306002)(55016002)(2906002)(7696004)(33646002)(6916009)(189998001)(42882006)(2900100001)(84326002)(53936002)(512954002)(9686003)(86362001)(54896002)(2351001)(86146001)(110136004)(260700001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR03MB3089; H:032-smtp-out.weatherford.com; FPR:; SPF:Pass; MLV:sfv; A:0; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11FD045; 1:IM5BgDcorDN+Yc2E5ii2mF8KFeeclFlYQGmoGOPMH/IEMOkL5qH1TGeu0Vox/O4P5HrXwYV/l5ELG3lJaJWURfHRr8feTJmS73iYjJd1c5A00TAt/bXq9+P0y4fbC5SOcNJY8g5Z87x3WtQvAuzGn7uJ4QWF0b7/HTCF4oXkP6o76fRi/ppMisAvxxHjE8TW1zGbZd4hVNKg5fNVTv1Y7OLyg68apq7re9MxuCCacLuqGRQCuylRIUfOIjBuDroN8q6y+hBVcPKziaPLNP88vNgCk/g8nUh5255xaE2YodmvSlnNtgd4GR5OUtoN5zz2uo0X+aXqf148u/5cl9nDM9aEx+uAwjTQexLnWnzcmiv8S520E7PmDrVlljDWMfXpBOgWqzJ+EexZ0F38C+PW081RatwDGCOe5G+PjsTz2W13kJVnFvT7zF6d5Tw/xjsWvyzBMu2fgi5/g7Ie9cWjt+dbf8NdSVZyivLn0zPubfc/9SFWBunOaOqW7/JnA2bwSvdkZANj2y2dbasR0rtAtw== X-CrossPremisesHeadersPromoted: BN1BFFO11FD045.protection.gbl X-CrossPremisesHeadersFiltered: BN1BFFO11FD045.protection.gbl X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(8251501002)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:BN6PR03MB3089; X-Microsoft-Exchange-Diagnostics: 1; BN6PR03MB3089; 3:o0OB+mz2TyPdPqLbDiJoGauXo+/oL1BmhvMlQAR4/rdGaYAh0q/R41CHq0SinaCkdOAP1lzRZJ7zwFEoBeVkVt/NLFvpvRhwcErRofv+AG+AzjCNaRwvETXUYL7VvBllSmsqwVtDe+c7Bp39+Ca1BfLu3PKpxYELLaa4WigYRQTBha+OqQUaFcJ4OgFC1Oefbx6w/GWjs/Tltb3LgpO7ZKTVJTzuzfrFdjmAecR1V4mikiZf4VElK47zxv8IUZaM+mtS+y7P4FPW23xXFZTlvlKa3X4uyBM8lc1s//ciMgcvFIa+O57R5G5DUoF9JG3pqTn9xG1Hab7e1jl3e6LQ9yl5h41r1zoC9pwomCYzcdhej3eWxaTUh8MmiL405yb8zwAK9h7cBZdBXdzYGgbWPDsh8Ekd52E9DK723pIF5O/dku7Jqg7DwvSpyTxzXfjrLYGCsthmY9VKE31aVwKXkCeluxeElF/RJDFjyKj//EmC2W6fIgIqZFo6cltuLLVb9aYUNWRxKPnTEgt1d8Rxwg== X-Microsoft-Exchange-Diagnostics: 1; BN6PR03MB3089; 25:j3pjrQsIuY8TgIdI3K1aVJko0YJtp4nGYDp54u66QwCkFI6TcsAfVKELJ6E1J3yhQZszWwIbKj5fVIwcnb5ZweVf0yaA3A356a/lQmoWa3uekiEJHcohv/rrl+dXkJN7qTwPhFGWO4hab5Yi2D9NXUo0H/R9EvR7wQd4d0X/gWDgVTfonNVjCTzP/trPe7C+y7sNSNz+PjqdiwmtQDuSYNihZOUB24DwmPE3U3EJaORoEc2q4xApmT+n5qctjKrDM1FL3OZkdiSw9Mh37GHpkDSlVFpUzLyR2HgBOw1oISgdYO4oLp+tDXiSV8P4NIjNEO9lRR2+juEOUrzfbAvLuxYh4LU7wlqmBiRXiQ7pELqJw/oFN/ZZSlKHo12UvCuM/GCUjrj2q9tLYu/22NjgrfwFfXrGHuYnfx0oJtpQyY9VY9AiFv7DiInMao25Gvv5YEmYHHEnLLYnPp1ECg8azU8w+EwMAWRfD19zIczt1Ks=; 31:7kPWR79c6AYbs+SaehzVwyuKg4/Ccc4A2cmOxrDCdKFYlivcrF02F7O96kkExfGfw6JzyInbgrQqNUaU+bifMqeLDrN7mnORBlSGxQm7Pf6izCKDICrDA+J2HdKy3mPagxurbJPOW7tRe0x7bGpnlQV8HTTv+6iEEhRIOLiydU1FL5ZLSIxJ96CVRIMeYQm6jaVr6Cz2NSHhuAL9+P9qHHESKtYqs67sQwqII/2PelbB8KH80KRdglOjwqxRhAkf3HDmiI1JpvzqfHc6WVoLEA== X-Microsoft-Exchange-Diagnostics: 1; BN6PR03MB3089; 20:Ppmt4EtPbnWm8ZxRS2zXSBHOJKAjs8EM2s3NucdQDov5P7bNvRfiwXe3sQa2UEpSCvhxGB/sJLL6nxE7o2T1OaK2bnN/x4CIqpQSn5NWC1kam5NhgsHc4AZXcTocbE4yzXVVuZWtu1O858zs+NcpTWZ+Sgw/phyl4RNcbnhfp9Xbaqux6Y6VKQpecHJv79MGnfh/rTsN7uUCvwGpnnjL6HnaZWA/+m0mIiWVCqaUjl+qff6YbYRxkwvT2RGAE5zTyGm+GdaKknMlGz0CLyYnqADQoMbmPFG5SQu1BgXnpwG8R9e35WPMR5MaM1ThfhI1Hkft+tuI81I0GMPF+e1cx+9iTKD1s0sKJanm5pG+9yQUmhIazmPeUYysW9L2y70MlDeT8lfDHgfusZqwDAAek9Nwa/pNtPkgLdskgVxtdVPziIdOTYLxPcUCEe2+ETgYuH+9PkP9BI6It9VebaD/qzDPFFoppen7vGQHYtiH81LNX8OXEQGFAxKU/0fo8ZZ8 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(192374486261705)(21748063052155); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(11241501159)(6040450)(601004)(2401047)(13018025)(5005006)(13016025)(8121501046)(93006095)(93004095)(10201501046)(3002001)(100000703101)(100105400095)(6055026)(6041248)(20161123564025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN6PR03MB3089; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN6PR03MB3089; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN6PR03MB3089; 4:i8pq3EbHN4bfjJSxIV8+oss15L8J9K+9K7VCJApqKI?= =?us-ascii?Q?sFYZ3fCews7asvSj/caLbAPljrO9NnJaOElfl21mNCx5y59/xhFijzNQMuaK?= =?us-ascii?Q?yaifyeOq0BG91AVcIhUNCvK7Rxd9Zcn7AtKjRl534x5CBIRyc8p9pNjvB1FQ?= =?us-ascii?Q?T/ffH6PMlEVRmhAfuDCBSGp/rItH6tgHEbcBGCWdOr3z56lc5xJNuTMZutnb?= =?us-ascii?Q?CgbI7i1ouk8MEJWoV08veSEZgI5+10u5L3ndK1t9jRwTOfbPUUfNvA9Fhc8C?= =?us-ascii?Q?LquSzCJKi/nWozw1xSUxwXp2OGLVlLkCgXs5c/ujcaMMVRPbQy1vUNF1Nx9U?= =?us-ascii?Q?s3U0lLbB4A686cIQDw+upxc/AayO1PC12P/klSaYLn62lmwSoY1TcREKIn1j?= =?us-ascii?Q?lnRyVFuxSSxblf2g6ldhE151OvvmcdyshaUurh7v8CdwJiLXLZG97JDtmfwZ?= =?us-ascii?Q?dXmHebKD89PfYTc1U8h0AmbwSJyuy0HY7ARq/xmGG2DjwgFqyO/tYOkMNP2y?= =?us-ascii?Q?sK0wLpx/TPCoXqwmzwICdU814e19CSVrsQT5VSgE+eF/vGtXaGPcr2tt2TgI?= =?us-ascii?Q?oT0ZbQlsJdfruOG69rtfS9pD7b7/Q9ljOYRiDni4PvxAlDKO+CbKWdAmDE6U?= =?us-ascii?Q?tXThpZd5I1BlNTL6OIklqVNDoxwmi4bSd03CIRCWCaVbYn4pFSYZL3c7El/T?= =?us-ascii?Q?DtgY2K43br1YhwkdAp1zM0+SN1LorAJaKWK4DStLagMnpISf9MuFy/rNDLZN?= =?us-ascii?Q?rwFCX2Lc+hntyUE8nvbfslxvWu0xiaALY9oFGADt0NW9IiH1CxL8ZGMRZRfG?= =?us-ascii?Q?NH0cSZa7dLQ785iIG17ejfR2Syto2zXiCHWZFlR30bQfh/0gJ/z64DhO6OUV?= =?us-ascii?Q?rKJNVMTT/xXlqefsFHcuFqpKm/pVWMd7lz2eJp6LObf3EPdUjzJTR5/2f2X+?= =?us-ascii?Q?iV1/Nxn1l6nWEeIpBk0QDKjhLq4cA8SUw9P8+t4MP5QppPp/wO3nKQ5i7G9q?= =?us-ascii?Q?W4u3QfnsipY0s8ILR/wqB4gBWC5+ncA9ngaIkwkD/d5zuwsguzQEg4zfXotP?= =?us-ascii?Q?pZo9BUq/pMiEzU/2R2wikqgDxuN7rXLQ/TnaJ0Jpjtso17KJfksAy7hkgOTA?= =?us-ascii?Q?BGhO58N2gQ6tIrXbM0NN3vZTCNIZN84m6ZixlH5mh/ghWH6FngGvlf9VkfJG?= =?us-ascii?Q?mRo95/9mZ7jUjMHC0u15cFmLTLeYGqZ7bPt6c0/TYVcLG/+/maQ3+jd0G1ZG?= =?us-ascii?Q?vYPnOxgpHzpl4m6qz8firScdeMA5NpNOkeXfhj7OCVBtO1P9+DbvgnclN4j6?= =?us-ascii?Q?cC6ARijwNxdTiFSqX0gfC5cZb9RoGjtu5L4Yf0b/FN?= X-Forefront-PRVS: 0334223192 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN6PR03MB3089; 23:o7+JC860MyZxNqdVbDMQZ8hWitpFISf4dtBmNmPET?= =?us-ascii?Q?6BWTwELEqUATKsBnygJQn4ihO39RuNqgq5ZiIKrX+Rb6C7e853DBd+2syXbh?= =?us-ascii?Q?SdiGpfO6IS9+0T7Rhu3EtPNH6uf5R1ryLHlQ6c1IA4ihAltLPkpdAEz5OHrC?= =?us-ascii?Q?Q/u9+WOMwovMqv7jaOv5IorG9BMMitCdX1E9c2zl9ylySE1JCJ7+CMfdclEx?= =?us-ascii?Q?99Q9yniHC6Ta5iYxU5gEGmWwgYjdjUnFkO9egRlWVmkLLQvmfUbtJTRW6grz?= =?us-ascii?Q?TLaw04MfCfvfQL9nsOUdry9SBmU2psrjheycj+m2OfsAjx/YlfvXud6YE6M4?= =?us-ascii?Q?2OVYNKN0A70WeWi4G6DitSRgEd4Eky4ep0ol/cQss1VUqUmd1bCxETXOwgvk?= =?us-ascii?Q?+dbvPmh8b0wURzNmK8Xk1+480aFgT7Tw+M4yQoNxUlOXLhITb07CRggjW64g?= =?us-ascii?Q?8r5cs211EARr5vfhlu3a+LEyrMehFg/62P2dXqxmJJLPivvZ8D4hgDa3ma7q?= =?us-ascii?Q?U4ivRZCxAedlU99znoNHQ/5oYm1oGPtri5SOCy25Si71VXUOfeMUIv9Va3Tw?= =?us-ascii?Q?kKNgbYSvv8M7U5dHl6yOXIUxO+3XQMImAOvlKDMyTJm9/nsnDK9/nUqR8LGM?= =?us-ascii?Q?tguNJR8UlNL1VJMNFFDIrRBkUV3ZKfT5oeG428oLIZGwGS4YnYRihHUmzECX?= =?us-ascii?Q?IE47pP+rLpuJJoWRpRYRZf1IiEBPjV6fxgIiixm9idLz/yjCg/09MCRdBZSZ?= =?us-ascii?Q?MgN98LJuJD7Wmuz374mwzZRO87a3B31yAwAboiO9y//uxrnyBPa9z3/TbOPY?= =?us-ascii?Q?Ik5MeA8OQbdo9s/hCa/fRAPJ+tVLygyBMnM7Zzenpz04cSvSWeUSFLvWYwdF?= =?us-ascii?Q?KCsDY9QXQ6nZSbJMh5I5J9qbj28RRG9BZhXaE+pEiY7f2sHBSHQG4XLwWtcX?= =?us-ascii?Q?Fo+POdoQNIEJ76jcxzYBu5Oklnizfg8T3MG+gbmlpWJ0kRADmAJV3nTQ8xNc?= =?us-ascii?Q?hQR8MpM/mqse5TVN4/9D664Jtp7oB/IpuI3ZeWjgpXQ0qlUEWvCtnia05tPz?= =?us-ascii?Q?CJQduzqjJcrofEnLKKgSDXei37zYgkNym1FEImmZTpNvwYIsXbcVsNlEZMtM?= =?us-ascii?Q?/B7X6TF7LtY6opGoSBre3BaiZnSz29hq3OrRfWXnPiiOuHebJmTNK1c7Ickr?= =?us-ascii?Q?nUVW5qp0/wO60yIMlCso1kwOCtZWlOT4oNVTlRvzKZx4jNLDq80nI4zN8Lwg?= =?us-ascii?Q?gD53UEUklwjgPmmpJqYdc/OOWCky0Wf6U7ij3AG?= X-Microsoft-Exchange-Diagnostics: 1; BN6PR03MB3089; 6:j7H8timO6M8CuptpNTb0pR+Xd99/H1CXvDgNLzuLCchmxU/QH3m4yVPsEgMTqKQi8JNeMozrq66pfaCjr91DvMlsCB8jU1Z1JLfcTo+8bQn4VgumsYZa56y9LrDHh7dks0qFLp6w6sHe/Vb70yAQhWel4uGv1oFa29pgrWzhVpEFywT3UkpMzTvW+qZmin0NPIuWK8nykvEf2hIyE8oWnyN1kJGLLzP/G+jyD+yMco+hR9sBlYEcm1M73aQQJo7xs1e3Dj/tZyrd+q61dDkqT8TvgJ59rfe3/b9OoGkBDWvF2m5VJnNPN28hUhftFVMJO1Di7DXmPMW3RmqynKxpHjXQh5C2KSVY3mw3YPuatvfa15b5uc+3jVBXxpjhM1wEHdlshPWwzNrqQS/t8G+RRvYlejwUC8nikYfFWHsRxI0Bez80On9WZBkVNZvN0I0HNQw4eEJ20quGWVdw7YwPbBQ6RmBUmH5yy9hS+6Ei+1QKR3RbrHVg0cL7hJue3ndYNqEwAujQhX+yKR7IBjaPOO/T0jcWm8f16ScukCHqq/g= X-Microsoft-Exchange-Diagnostics: 1; BN6PR03MB3089; 5:OzBlHDoAOKU3tJpE+UrO0r594sxS9pAskGS8xIko+lWKFNSea3bgOAdK12g1Veu8921Tsik7TpVkzEPnjcMYi+y+xnzXY5jVCs+fAC4jdND7uuicBMIdJiSHQrTfzQHVDFZUMCqlMD9YAXO5Jq/HQDOglLxi3aRiTmcJuiCIinY26JsBU2lupgvQ4q0GpUA3ju+WS+P1shijSBEx61YH53fpvnxFY9V2EC3Zj0iNvPu+HgnAOL9GhdXSB4wWiPzRjcrBoJNk4qli30ubw5KaHll/C6AVUL4bksVBk+pQ7QskRdq/TIj7PS1gT8IgvzRrJAshFlRFEdMdjdNRYqzCDl8G56lTIWutwxHpT/+y+G+KRnoCnorgU7R/qQNKt/UT1m61ulvOk8tDniJKXsYPdQ9mJxMuy7J+lukJmE8fepUOsxAGFtlP5EjSjBNrED6b6qG72YsKU30tXwPtDpJMC6LKE03zkJ13yTg230g+Ak+BCOgcor8eXv24qCOrBrkX; 24:60V/R9GnEFu0DqJV5x1KtVFGC8Mke0WjypulSDMJcw1Lfbiz0TWduCpob+z2a7mcrxgMhfyRAFI/jdN5vA1GFponlOQ7evoXzwWefL9IypA= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BN6PR03MB3089; 7:EoRk6EgcvUvI+mnjdxAMvvnl0UbWTH9q9YXzfTnic1KWVN61vMfwnMM8Kts/arP5FQgh0phM0rHMyuYa6U5aYO8JrdCE1V12WjpGToMaO5epFQa7Y/kS+fkIX5Z0aM/XAOJgKPvtfSEpd52SYbnsrhf12aQAyXvFjoFtBMfHZYwYBFNYdxgT+riaccI7/USDKtdkDhgBTsOayW/D4BnnBLoyAp0aP/R5sRJ3jworCpFCRDqlvBzhPwZe4c/GPDuDyoYa0BImMQ/nESro4yVnB1DVHChvTpGPSaJ+KB+MMqaud/XZUQ3AVNImfRL2i7FQV6TFtikt2XEkP1zceo5X5w== X-OriginatorOrg: ca.weatherford.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Jun 2017 16:26:00.5212 (UTC) X-MS-Exchange-CrossTenant-Id: dd63fb60-07f6-4d96-8d40-ebeca61a524e X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=dd63fb60-07f6-4d96-8d40-ebeca61a524e; Ip=[23.103.226.20]; Helo=[032-smtp-out.weatherford.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB3089 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 16:26:04 -0000 Gents, I'm experiencing an issue where iterating over a PostgreSQL table of ~21.5 = million rows (select count(*)) goes from ~35 seconds to ~635 seconds on Int= el 540 SSDs. This is using a FreeBSD 10 amd64 stable kernel back from Jan = 2017. SSDs are basically 2 drives in a ZFS mirrored zpool. I'm using Post= greSQL 9.5.7. I've tried: * Using the FreeBSD10 amd64 stable kernel snapshot of May 25, 2017. * Tested on half a dozen machines with different models of SSDs: o Intel 510s (120GB) in ZFS mirrored pair o Intel 520s (120GB) in ZFS mirrored pair o Intel 540s (120GB) in ZFS mirrored pair o Samsung 850 Pros (256GB) in ZFS mirrored pair * Using bonnie++ to remove Postgres from the equation and performance= does indeed drop. * Rebooting server and immediately re-running test and performance is= back to original. * Tried using Karl Denninger's patch from PR187594 (which took some w= ork to find a kernel that the FreeBSD10 patch would both apply and compile = cleanly against). * Tried disabling ZFS lz4 compression. * Ran the same test on a FreeBSD9.0 amd64 system using PostgreSQL 9.1= .3 with 2 Intel 520s in ZFS mirrored pair. System had 165 days uptime and = test took ~80 seconds after which I rebooted and re-ran test and was still = at ~80 seconds (older processor and memory in this system). I realize that there's a whole lot of info I'm not including (dmesg, zfs-st= ats -a, gstat, et cetera): I'm hoping some enlightened individual will be a= ble to point me to a solution with only the above to go on. Cheers, Aaron This message may contain confidential and privileged information. If it has= been sent to you in error, please reply to advise the sender of the error = and then immediately delete it. If you are not the intended recipient, do n= ot read, copy, disclose or otherwise use this message. The sender disclaims= any liability for such unauthorized use. PLEASE NOTE that all incoming e-m= ails sent to Weatherford e-mail accounts will be archived and may be scanne= d by us and/or by external service providers to detect and prevent threats = to our systems, investigate illegal or inappropriate behavior, and/or elimi= nate unsolicited promotional e-mails (spam). This process could result in d= eletion of a legitimate e-mail before it is read by its intended recipient = at our organization. Moreover, based on the scanning results, the full text= of e-mails and attachments may be made available to Weatherford security a= nd other personnel for review and appropriate action. If you have any conce= rns about this process, please contact us at dataprivacy@weatherford.com. From owner-freebsd-hackers@freebsd.org Sat Jun 10 16:36:51 2017 Return-Path: Delivered-To: freebsd-hackers@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 6AA6DBF177C for ; Sat, 10 Jun 2017 16:36:51 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2BEAE7EE78 for ; Sat, 10 Jun 2017 16:36:51 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1dJjNS-000Fu6-7G; Sat, 10 Jun 2017 19:36:42 +0300 Date: Sat, 10 Jun 2017 19:36:42 +0300 From: Slawa Olhovchenkov To: "Caza, Aaron" Cc: "freebsd-hackers@freebsd.org" Subject: Re: FreeBSD10 Stable + ZFS + PostgreSQL + SSD performance drop < 24 hours Message-ID: <20170610163642.GA18123@zxy.spb.ru> References: <79528bf7a85a47079756dc508130360b@DM2PR58MB013.032d.mgd.msft.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <79528bf7a85a47079756dc508130360b@DM2PR58MB013.032d.mgd.msft.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 16:36:51 -0000 On Sat, Jun 10, 2017 at 04:25:59PM +0000, Caza, Aaron wrote: > Gents, > > I'm experiencing an issue where iterating over a PostgreSQL table of ~21.5 million rows (select count(*)) goes from ~35 seconds to ~635 seconds on Intel 540 SSDs. This is using a FreeBSD 10 amd64 stable kernel back from Jan 2017. SSDs are basically 2 drives in a ZFS mirrored zpool. I'm using PostgreSQL 9.5.7. > > I've tried: > > * Using the FreeBSD10 amd64 stable kernel snapshot of May 25, 2017. > > * Tested on half a dozen machines with different models of SSDs: > > o Intel 510s (120GB) in ZFS mirrored pair > > o Intel 520s (120GB) in ZFS mirrored pair > > o Intel 540s (120GB) in ZFS mirrored pair > > o Samsung 850 Pros (256GB) in ZFS mirrored pair > > * Using bonnie++ to remove Postgres from the equation and performance does indeed drop. > > * Rebooting server and immediately re-running test and performance is back to original. > > * Tried using Karl Denninger's patch from PR187594 (which took some work to find a kernel that the FreeBSD10 patch would both apply and compile cleanly against). > > * Tried disabling ZFS lz4 compression. > > * Ran the same test on a FreeBSD9.0 amd64 system using PostgreSQL 9.1.3 with 2 Intel 520s in ZFS mirrored pair. System had 165 days uptime and test took ~80 seconds after which I rebooted and re-ran test and was still at ~80 seconds (older processor and memory in this system). > > I realize that there's a whole lot of info I'm not including (dmesg, zfs-stats -a, gstat, et cetera): I'm hoping some enlightened individual will be able to point me to a solution with only the above to go on. Just a random guess: can you try r307264 (I am mean regression in r307266)?