From owner-freebsd-arch@FreeBSD.ORG Sun Jan 13 01:42:48 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D4B83BF5 for ; Sun, 13 Jan 2013 01:42:48 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id 8EA77170 for ; Sun, 13 Jan 2013 01:42:48 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.5/8.14.5) with ESMTP id r0D1ggPY061704 for ; Sat, 12 Jan 2013 17:42:42 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.5/8.14.5/Submit) id r0D1ggUt061703 for freebsd-arch@FreeBSD.org; Sat, 12 Jan 2013 17:42:42 -0800 (PST) (envelope-from sgk) Date: Sat, 12 Jan 2013 17:42:42 -0800 From: Steve Kargl To: freebsd-arch@FreeBSD.org Subject: Re: how long to keep support for gcc on x86? Message-ID: <20130113014242.GA61609@troutmask.apl.washington.edu> References: <20130112233147.GK1410@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130112233147.GK1410@funkthat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 01:42:48 -0000 On Sat, Jan 12, 2013 at 03:31:47PM -0800, John-Mark Gurney wrote: > So, now that -current x86 is defaulting to clang, how much longer do we > need to support gcc on platforms that default to clang? IMHO, gcc should be available until after 10.0 is branched. > I'm asking because clang support AES-NI, but gcc does not... The last and only time I had for testing clang's handling of floating point revealed that clang had a few bugs and performance issues. -- Steve From owner-freebsd-arch@FreeBSD.ORG Sun Jan 13 03:31:00 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 77828FFE for ; Sun, 13 Jan 2013 03:31:00 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 154E362F for ; Sun, 13 Jan 2013 03:30:58 +0000 (UTC) Received: by mail-wi0-f182.google.com with SMTP id hn14so595351wib.9 for ; Sat, 12 Jan 2013 19:30:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=dvbhXSnjklsHwBZAUCGxx7pvnSg6BsK34SF8TFX+rko=; b=aMMNQSGeL65RLe+15Z8TLVrf9R0ebLAqK48pwArRJGkFUDMwgEYm9Kmn2k84TLG3Zz 5CiE7SFDbLiJQhrTz0OhvmW5hOLMIkrvACyTBxAKLglshaHi0gZsRMqJjBKyyvots1Mq F5132fWOHzbiqjM9xuelLLPFj+3Csh7qxENrbWTARrAK1BkVXhZ1tVoBhFrNYxqnVphH q9JIxJIf/fRvAOow00vqLbaRTE6ipL55tNWU/1sHV3GIq8mxS9fLPrc+UicFNLyLAEoB 1/4pofBX2ZTmFH03xZHOTqyKfS0GOeQA9shcfcuszjbko3Cy5jdntmCLRzDgm8NJlsdi z7tg== MIME-Version: 1.0 X-Received: by 10.180.93.133 with SMTP id cu5mr6062705wib.32.1358047857877; Sat, 12 Jan 2013 19:30:57 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Sat, 12 Jan 2013 19:30:57 -0800 (PST) In-Reply-To: <20130113014242.GA61609@troutmask.apl.washington.edu> References: <20130112233147.GK1410@funkthat.com> <20130113014242.GA61609@troutmask.apl.washington.edu> Date: Sat, 12 Jan 2013 19:30:57 -0800 X-Google-Sender-Auth: YCMkxuIvbbf_NqWDr2Cgjz9WOVM Message-ID: Subject: Re: how long to keep support for gcc on x86? From: Adrian Chadd To: Steve Kargl Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 03:31:00 -0000 IMHO gcc shuld be available until all of the platforms that we currently ship FreeBSD on gets clang support. This includes MIPS (which is there, but I don't think the default MIPS build uses clang at the moment) and ia64, which Marcel has been dutifully working on. Please also note that people can and will compile FreeBSD on a non-default-system compiler ; so deprecating gcc (either support or framework) should be considered carefully. Adrian On 12 January 2013 17:42, Steve Kargl wrote: > On Sat, Jan 12, 2013 at 03:31:47PM -0800, John-Mark Gurney wrote: >> So, now that -current x86 is defaulting to clang, how much longer do we >> need to support gcc on platforms that default to clang? > > IMHO, gcc should be available until after 10.0 is branched. > >> I'm asking because clang support AES-NI, but gcc does not... > > The last and only time I had for testing clang's handling > of floating point revealed that clang had a few bugs and > performance issues. > > -- > Steve > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Sun Jan 13 03:32:50 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 739EB12F; Sun, 13 Jan 2013 03:32:50 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-f174.google.com (mail-we0-f174.google.com [74.125.82.174]) by mx1.freebsd.org (Postfix) with ESMTP id 48E8C637; Sun, 13 Jan 2013 03:32:48 +0000 (UTC) Received: by mail-we0-f174.google.com with SMTP id x10so1492768wey.5 for ; Sat, 12 Jan 2013 19:32:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=lCBAz13WFsabfAqfXtgIO0i8yXz6sLJj3nK1o66fi34=; b=IC+369ljYjOVdEBVnVC57A9Hc5uNgUWhao2zo2bF23eCXHo6vTdr2GffT/IFPLkbX+ t8qFnwj3+TM3pYOh8XZZFU9rwaSefR7/YbvqGxHdQlboe2Fl57qyZEz5FrcPAg96EjEr Ucb6nZDdVLJBhoQxhEMRt/A3HFefkMFZnXc8b/PlYArqzGrll1TKg6HGfrALX30PLV1U K1i5e4DSoDjVjJd2z5wFg5wcLGqnAMvsVCdN7KK+R8yO5ODPLk9tTjgbkTYBpLkRdjwQ qb4PErzAVRl0nf8A0yx2dp9szCfKgTb068VRUVduULfiVxLvLlhG3zCc9QpJkiTUhqii WTcA== MIME-Version: 1.0 X-Received: by 10.180.33.44 with SMTP id o12mr6249141wii.28.1358047968150; Sat, 12 Jan 2013 19:32:48 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Sat, 12 Jan 2013 19:32:48 -0800 (PST) In-Reply-To: <50F1BD69.4060104@mu.org> References: <201211272119.qARLJxXV061083@svn.freebsd.org> <50C1BC90.90106@freebsd.org> <50C25A27.4060007@bluezbox.com> <50C26331.6030504@freebsd.org> <50C26AE9.4020600@bluezbox.com> <50C3A3D3.9000804@freebsd.org> <50C3AF72.4010902@rice.edu> <330405A1-312A-45A5-BB86-4969478D8BBD@bluezbox.com> <50D03E83.8060908@rice.edu> <50DD081E.8000409@bluezbox.com> <50EB1841.5030006@bluezbox.com> <50EB22D2.6090103@rice.edu> <50EB415F.8020405@freebsd.org> <50F04FE5.7010406@rice.edu> <50F1BD69.4060104@mu.org> Date: Sat, 12 Jan 2013 19:32:48 -0800 X-Google-Sender-Auth: 52LCZPns2O474AuVy9F2QvuVIaA Message-ID: Subject: Re: svn commit: r243631 - in head/sys: kern sys From: Adrian Chadd To: Alfred Perlstein Content-Type: text/plain; charset=ISO-8859-1 Cc: src-committers@freebsd.org, Andre Oppermann , Alan Cox , "Jayachandran C." , svn-src-all@freebsd.org, Oleksandr Tymoshenko , freebsd-arch@freebsd.org, svn-src-head@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 03:32:50 -0000 On 12 January 2013 11:45, Alfred Perlstein wrote: > I'm not sure if regressing to the waterfall method of development is a good > idea at this point. > > I see a light at the end of the tunnel and we to continue to just handle > these minor corner cases as we progress. > > If we move to a model where a minor bug is grounds to completely remove > helpful code then nothing will ever get done. > Allocating 512MB worth of callwheels on a 16GB MIPS machine is a little silly, don't you think? That suggests to me that the extent of which maxfiles/maxusers/etc percolates the codebase wasn't totally understood by those who wish to change it. I'd rather see some more investigative work into outlining things that need fixing and start fixing those, rather than "just change stuff and fix whatever issues creep up." I kinda hope we all understand what we're working on in the kernel a little better than that. Adrian From owner-freebsd-arch@FreeBSD.ORG Sun Jan 13 05:37:27 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2611634E; Sun, 13 Jan 2013 05:37:27 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) by mx1.freebsd.org (Postfix) with ESMTP id D885B815; Sun, 13 Jan 2013 05:37:26 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r0D5bPck086573 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 12 Jan 2013 21:37:25 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r0D5bPnB086572; Sat, 12 Jan 2013 21:37:25 -0800 (PST) (envelope-from jmg) Date: Sat, 12 Jan 2013 21:37:25 -0800 From: John-Mark Gurney To: Adrian Chadd Subject: Re: how long to keep support for gcc on x86? Message-ID: <20130113053725.GL1410@funkthat.com> Mail-Followup-To: Adrian Chadd , Steve Kargl , freebsd-arch@freebsd.org References: <20130112233147.GK1410@funkthat.com> <20130113014242.GA61609@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sat, 12 Jan 2013 21:37:26 -0800 (PST) Cc: Steve Kargl , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 05:37:27 -0000 Adrian Chadd wrote this message on Sat, Jan 12, 2013 at 19:30 -0800: > IMHO gcc shuld be available until all of the platforms that we > currently ship FreeBSD on gets clang support. Though, we have a very ancient version of gcc, a modern version would support the AES-NI intrinsicts that I am thinking of using... It's more of a question of how long do we need to keep support for gcc 4.2.1, not another modern gcc/other compiler... > This includes MIPS (which is there, but I don't think the default MIPS > build uses clang at the moment) and ia64, which Marcel has been > dutifully working on. > > Please also note that people can and will compile FreeBSD on a > non-default-system compiler ; so deprecating gcc (either support or > framework) should be considered carefully. Considering that the icc stuff was recently removed, unless the compiler has good gcc/clang emulation, I can't see how far another compiler would get compiling our code... > On 12 January 2013 17:42, Steve Kargl wrote: > > On Sat, Jan 12, 2013 at 03:31:47PM -0800, John-Mark Gurney wrote: > >> So, now that -current x86 is defaulting to clang, how much longer do we > >> need to support gcc on platforms that default to clang? > > > > IMHO, gcc should be available until after 10.0 is branched. > > > >> I'm asking because clang support AES-NI, but gcc does not... > > > > The last and only time I had for testing clang's handling > > of floating point revealed that clang had a few bugs and > > performance issues. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@FreeBSD.ORG Sun Jan 13 07:44:52 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 52E0D55C; Sun, 13 Jan 2013 07:44:52 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by mx1.freebsd.org (Postfix) with ESMTP id 03929A6D; Sun, 13 Jan 2013 07:44:51 +0000 (UTC) Received: by mail-vb0-f44.google.com with SMTP id fc26so2737520vbb.3 for ; Sat, 12 Jan 2013 23:44:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=jgor3MdSJXlZ7vVYqJfGEKW5aMqtjzXgdF/p8KdV6po=; b=oJoUHIBlS/Njb9c+KRlUK2VctNd/lgjeAehl8fVfvYvURXD6J+slUv0h6NP5oYbHlS wNcd8EA7+vyQZdTJuWl5Gg/KeLdZiNq6HnynMjFvmJVGCXXQ4I4L+Z0APYf1XyHMFY6/ 7H0e845au2j5GxFmfgL2ZIYXl1Vca+XLXMFFlF39MRygsesjofiurpYjVm8k6+9fUkSk b5lN09Rz+jxUt9+OHSGXsmbJ4+QAcJnb6S4f322DmKQV+QWDaJnyPj5uj34XPiVCdrNH Gzgrl4SDN9bDI3KSdw0Isnr2A/azDodipiear81H1V7eEHZiO/e/9Nz3Ilh18zUvbXNq 3Epw== MIME-Version: 1.0 Received: by 10.52.77.40 with SMTP id p8mr980766vdw.98.1358063090999; Sat, 12 Jan 2013 23:44:50 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.58.132.212 with HTTP; Sat, 12 Jan 2013 23:44:50 -0800 (PST) In-Reply-To: <20130113053725.GL1410@funkthat.com> References: <20130112233147.GK1410@funkthat.com> <20130113014242.GA61609@troutmask.apl.washington.edu> <20130113053725.GL1410@funkthat.com> Date: Sat, 12 Jan 2013 23:44:50 -0800 X-Google-Sender-Auth: 8Vx9YGPZOwIsNwYczRoKQapHb3c Message-ID: Subject: Re: how long to keep support for gcc on x86? From: Adrian Chadd To: Adrian Chadd , Steve Kargl , freebsd-arch@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 07:44:52 -0000 Hi, People are still ironing out kinks/differences with clang. Anyone saying otherwise is likely pushing an agenda. :-) Thus I think adding clang-only code to the system right now is very, very premature. There still seem to be reasons to run systems on GCC instead of clang. If you have a need for new instruction support, perhaps look at adding it to our base GCC for the time being? Remember, you're not the only consumer of the system. :-) Adrian From owner-freebsd-arch@FreeBSD.ORG Sun Jan 13 08:09:10 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BFAB26FD for ; Sun, 13 Jan 2013 08:09:10 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-vc0-f180.google.com (mail-vc0-f180.google.com [209.85.220.180]) by mx1.freebsd.org (Postfix) with ESMTP id 6F308AC0 for ; Sun, 13 Jan 2013 08:09:09 +0000 (UTC) Received: by mail-vc0-f180.google.com with SMTP id p16so2694876vcq.11 for ; Sun, 13 Jan 2013 00:09:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+HfH/S0lIIPVCSxwl5NZ6MPKMXajMR3XKNmUhZSMUcY=; b=IPJb/wc/N5TXBOAJvUcf1O7ALFPK/QJdziy/310AkBDKnJtVC46sGCjR3W6KNAlahE 9TboyI/R8K0HeUYGJPIvc4Bowwa1WRw6UwtdTUMD6nZrUWbCLQlg7CqBYD4tydrwbwK9 Yg2pPaApNbcyejkzcjDsl/Wn72Qb/QmUTf0ok= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=+HfH/S0lIIPVCSxwl5NZ6MPKMXajMR3XKNmUhZSMUcY=; b=EXjTecjroTukTFIbUi1YbH6JTgQqAfYZR/JO/BSJEy1Ce1VfKwo4xnMzrk/VzG6Ke8 0fPzFgiqGyfWExaftxKmmlAXgc84wJmN5f801jmerwFN07sz85Z8ErFsWmQoyIzidTyC 7LUPRzG83uPSoUNNgygBbcm1fw1BIdFwsYljyr9yiHWhOq8uAdVg3/Rq1KKK0prVqoPK KpeUERSxE4GygIwlPYKmN0YvvRiGIdD9eNH0K889K+BbZV3cOnk559ADQfIg4v+NutEc /UA5oNnuX9XUS4lJ10kI6XLLkGugVRGviNI49C6B/UO4zlsR3wT1sPVg75gZhp8Eff9c 4S4A== MIME-Version: 1.0 Received: by 10.220.239.14 with SMTP id ku14mr97607834vcb.57.1358064549332; Sun, 13 Jan 2013 00:09:09 -0800 (PST) Received: by 10.220.174.135 with HTTP; Sun, 13 Jan 2013 00:09:09 -0800 (PST) In-Reply-To: References: <20130112233147.GK1410@funkthat.com> <20130113014242.GA61609@troutmask.apl.washington.edu> <20130113053725.GL1410@funkthat.com> Date: Sun, 13 Jan 2013 00:09:09 -0800 Message-ID: Subject: Re: how long to keep support for gcc on x86? From: Peter Wemm To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQk3a3LEnsPlGgSXQbTnXq6gLKHPpZb0l/p83Tr+Nju/jpVpjS6k88zIZ3XvhEV0Ckl+nJRp Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 08:09:10 -0000 On Sat, Jan 12, 2013 at 11:44 PM, Adrian Chadd wrote: > Thus I think adding clang-only code to the system right now is very, > very premature. There still seem to be reasons to run systems on GCC > instead of clang. I don't have a problem with it so long as the system isn't *broken* if you're not using clang. ie: if the status-quo is maintained for gcc systems and g-faster bits are enabled with clang. It's fine to provide incentives to try clang, but it is not ok to regress the gcc case. eg: we did the same with gcc in the early days, or at least made a token effort. eg: you got __asm __inline with gcc, or regular assembler functions if not. It was never complete though. I use clang in general (and WITHOUT_GCC), but not on lower end machines like Atom boxes. They don't have AES-NI anyway. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV bitcoin:188ZjyYLFJiEheQZw4UtU27e2FMLmuRBUE From owner-freebsd-arch@FreeBSD.ORG Sun Jan 13 11:41:12 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7861951F; Sun, 13 Jan 2013 11:41:12 +0000 (UTC) (envelope-from edschouten@gmail.com) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) by mx1.freebsd.org (Postfix) with ESMTP id 87873F9; Sun, 13 Jan 2013 11:41:11 +0000 (UTC) Received: by mail-lb0-f178.google.com with SMTP id l5so2307642lbo.37 for ; Sun, 13 Jan 2013 03:41:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=4jKli5m4EB7eIUJUiMO91zQDfEmM6vAQ/RCk2bixb3Q=; b=SWOUqwqaGMBiHDQss0QRu49nudnw45KceGSRdOE+YizXNv/l60z1euYZqKK8B5WnXz 55Umf74QqhC5fNpM8WOVvpbCNXIk+D+3/kO1apO0OS7L+M2y8mgh3iM6oXCFkbuAmWSn CkpiNgbpSGalXFqmRui3lGPH4pB6GGc7xlFQknsI/03We1uJYC6WJVtIARJkIo2qR1TN RLeTBEG7sFlL3TUX94+w0zH+G7LEnsDA1wyBpQaa2YelG2XzgbNKxDuHDtOMn7SMFoHa 3rYSsSF1yugfEVchiCDdo3kfv98tBWRs/cLPL37LUdStN1OnK+wKoyB1+QE8CHex3T0K PBAg== MIME-Version: 1.0 Received: by 10.112.29.104 with SMTP id j8mr33916166lbh.0.1358077269998; Sun, 13 Jan 2013 03:41:09 -0800 (PST) Sender: edschouten@gmail.com Received: by 10.112.86.6 with HTTP; Sun, 13 Jan 2013 03:41:09 -0800 (PST) In-Reply-To: <20130107172433.GX82219@kib.kiev.ua> References: <50E9BC2D.7000302@freebsd.org> <201301070936.39052.jhb@freebsd.org> <20130107172433.GX82219@kib.kiev.ua> Date: Sun, 13 Jan 2013 12:41:09 +0100 X-Google-Sender-Auth: BjCr3hUA_5zzHOmzFatHQ1aJy2Y Message-ID: Subject: Re: LLVM Image Activator From: Ed Schouten To: Konstantin Belousov Content-Type: text/plain; charset=UTF-8 Cc: freebsd-toolchain@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 11:41:12 -0000 Hi Kostik, 2013/1/7 Konstantin Belousov : > I still do remember the buzz about the binary format 0xCAFEBABE, which > AFAIR gained image activator support on several OSes, to be garbage > collected. Maybe it would then be a good idea then to add some kind of general purpose remapping imgact? Example: /etc/imgacttab: cafebabe /usr/local/bin/java cffaedfe /usr/local/bin/osx_emulator 4243c0de /usr/bin/lli That way we still give people the freedom to play around with mapping their own executable formats, but don't need to maintain a bunch of imgacts. -- Ed Schouten From owner-freebsd-arch@FreeBSD.ORG Sun Jan 13 13:21:12 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 73F81617; Sun, 13 Jan 2013 13:21:12 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id E35703F5; Sun, 13 Jan 2013 13:21:11 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r0DDKvSg039763; Sun, 13 Jan 2013 15:20:57 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r0DDKvSg039763 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r0DDKvOh039762; Sun, 13 Jan 2013 15:20:57 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 13 Jan 2013 15:20:57 +0200 From: Konstantin Belousov To: Ed Schouten Subject: Re: LLVM Image Activator Message-ID: <20130113132057.GQ2561@kib.kiev.ua> References: <50E9BC2D.7000302@freebsd.org> <201301070936.39052.jhb@freebsd.org> <20130107172433.GX82219@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="htVlOAOs/VIaEhiC" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) 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 version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-toolchain@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 13:21:12 -0000 --htVlOAOs/VIaEhiC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 13, 2013 at 12:41:09PM +0100, Ed Schouten wrote: > Hi Kostik, >=20 > 2013/1/7 Konstantin Belousov : > > I still do remember the buzz about the binary format 0xCAFEBABE, which > > AFAIR gained image activator support on several OSes, to be garbage > > collected. >=20 > Maybe it would then be a good idea then to add some kind of general > purpose remapping imgact? Example: >=20 > /etc/imgacttab: >=20 > cafebabe /usr/local/bin/java > cffaedfe /usr/local/bin/osx_emulator > 4243c0de /usr/bin/lli >=20 > That way we still give people the freedom to play around with mapping > their own executable formats, but don't need to maintain a bunch of > imgacts. A generic module that could be somewhat customized at runtime to map offset+signature into the shebang path could be a possibility indeed. I strongly prefer to have it as module and not enabled by default. Asking Nathan for writing the thing is too much, IMHO, esp. in the response to the 50-lines hack. --htVlOAOs/VIaEhiC Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQ8rS5AAoJEJDCuSvBvK1BOS0QAIFUrY+SSfw7mrzHFFIlkdZr V1f/BD6ttZPTLWjxzkFh99xOgYikcxdwBHriz+y15pjNfp4qdsq1ShUvkeslGgfj mjmXXQeLcSERybNokzFzRJ4PehAQ7Nb0GjkYFZVstPBcBIF1WPgYBfw2m+LAXbwZ ru9WC4shXYyqX7i7vv3eJ5vybJAiy0KUSs1q24H6Vmxc3ouIBY9WXYtWO7HNw0oC SYuQ2Ns43qK36c3SpKFUSrAoFgyuVLR/aKfCCo0I3qeV0Wn+wmhE9Feni5I+q2Ar Qgjz23h3ZHTiux8bLa1CdWXt2Ayqa1hDzVTthPnsCJHLrLwbc7VcwCsW9i2O90ts Dm9irz/w9vneG7HIYgw2YAQKq9AJHSjLy0+OVXUpqnrO4LzfW1VHNh3h3tqlUJJ1 qhlOfzYb8qv0w/5Y2vMbP+fWFH76aFJeVCGSDd+bHSUvVqdICUNZFJRzlW3aAi09 xaZiF63Oi7kaU2gydCZ/pimVCPBaKsqlzkfwY++V0z6sVincxnnO2NqKyv3gYsXQ 4ARcChMpOJHqAzt9MlxQXkXIgE380rxnMWMB6VC66graZJ9Kx1QglZA1AN809w1e tZ2R5PM/ySwM4fYpw8VxHXhegEsG1aIirlVIWZQ/P6pcOgmp43ZF7SOk1Yi5MRQA igJsuK5VjMZpijPmo6mO =4znq -----END PGP SIGNATURE----- --htVlOAOs/VIaEhiC-- From owner-freebsd-arch@FreeBSD.ORG Sun Jan 13 13:24:11 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 01CCC6EC; Sun, 13 Jan 2013 13:24:10 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 97FCE61A; Sun, 13 Jan 2013 13:24:10 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r0DDO363039788; Sun, 13 Jan 2013 15:24:03 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r0DDO363039788 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r0DDO2VF039787; Sun, 13 Jan 2013 15:24:02 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 13 Jan 2013 15:24:02 +0200 From: Konstantin Belousov To: Peter Wemm Subject: Re: how long to keep support for gcc on x86? Message-ID: <20130113132402.GR2561@kib.kiev.ua> References: <20130112233147.GK1410@funkthat.com> <20130113014242.GA61609@troutmask.apl.washington.edu> <20130113053725.GL1410@funkthat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="en9/O5YN3eJ0yPaf" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) 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 version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Adrian Chadd , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 13:24:11 -0000 --en9/O5YN3eJ0yPaf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 13, 2013 at 12:09:09AM -0800, Peter Wemm wrote: > On Sat, Jan 12, 2013 at 11:44 PM, Adrian Chadd wrote: >=20 > > Thus I think adding clang-only code to the system right now is very, > > very premature. There still seem to be reasons to run systems on GCC > > instead of clang. >=20 > I don't have a problem with it so long as the system isn't *broken* if > you're not using clang. ie: if the status-quo is maintained for gcc > systems and g-faster bits are enabled with clang. It's fine to > provide incentives to try clang, but it is not ok to regress the gcc > case. Absolutely agree. Please note that in the AES-NI case, gcc 'support' is only partially gcc issue, if gcc at all. Our 2.17 gas does not know about AES-NI mnemonics and cannot assemble them. AFAIR the patch uses C built-in for AES-NI and SSE3 or 4, which I think could be implemented manually in the amount needed for the patch, for old gcc. >=20 > eg: we did the same with gcc in the early days, or at least made a > token effort. eg: you got __asm __inline with gcc, or regular > assembler functions if not. It was never complete though. >=20 > I use clang in general (and WITHOUT_GCC), but not on lower end > machines like Atom boxes. They don't have AES-NI anyway. --en9/O5YN3eJ0yPaf Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQ8rVwAAoJEJDCuSvBvK1BbcMQAJsAXyPX490PyqybhYkyKaui Wrh02YluVeWtQcZS9Y420/YdOzjjcEh3L69vqFaTSzI07HMvQAs95p0AmtrwLTq0 i1HhoRCcxIhXpw6M1IZtoy0QU+GW3jFaliUgWfUxUbjnS+L3jPp1ZXolovxIE2J2 R90hkLOML3mDSMyp3lGWArAAfmNAr45E94XawZ67PqWT/tXqqYrbNqhHytcEWbH+ 1Yv76JFpiLAxewblCZ64u53mynHOrbUPza4fbDMP4vwic8K/zZ8xgF91UNrgOiGH /DkF7iIhdIXeABIb66LLIkzpVDUUrgjUVOOtymgEU8HaSotM+1zt/16BeLUqLPdE u/EQdwn3sSANQbx6G44B4slTeV9a0TOpq2+hm0RueDjhpNKoPWiaGSKQJlA5mXAE PNYVy7vjtjZTXPO2QVxQS6Eehnim0RWfBe8INi04AzUDVolkethoXd8eu6ZnkiBG brsGbxDKOKnCZvVSMG/+3Wz16tGk3BmoprYmXawR9vMZUP6yYyVptcSUhdPBVhoq Qd7ye6sH2IcFzI+WuZopG5JNGdl+rMegEfk6ttvX4+XN3VJQfKsYwX7V/vIW1+0Q Im3hcnj9UtlimVi5OgGGVO+Qe1GHErl4vyEjzClE3/hcfnaavVVuty3Lo0MX5pqv 3U+rTcIY3axr39UsYalk =eCDJ -----END PGP SIGNATURE----- --en9/O5YN3eJ0yPaf-- From owner-freebsd-arch@FreeBSD.ORG Sun Jan 13 13:32:02 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D8D0A999; Sun, 13 Jan 2013 13:32:02 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id 9E2C963E; Sun, 13 Jan 2013 13:32:02 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 386A5359315; Sun, 13 Jan 2013 14:32:00 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id 197C72848C; Sun, 13 Jan 2013 14:32:00 +0100 (CET) Date: Sun, 13 Jan 2013 14:32:00 +0100 From: Jilles Tjoelker To: Konstantin Belousov , davidxu@freebsd.org Subject: Re: Fast sigblock (AKA rtld speedup) Message-ID: <20130113133159.GA72462@stack.nl> References: <20130107182235.GA65279@kib.kiev.ua> <20130111095459.GZ2561@kib.kiev.ua> <50EFE830.3030500@freebsd.org> <20130111204938.GD2561@kib.kiev.ua> <20130111232906.GA29017@stack.nl> <20130112053147.GH2561@kib.kiev.ua> <20130112162547.GA54954@stack.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130112162547.GA54954@stack.nl> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: arch@freebsd.org, toolchain@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 13:32:02 -0000 On Sat, Jan 12, 2013 at 05:25:47PM +0100, Jilles Tjoelker wrote: > This suggests a different rather simpler change. Libthr can always use > its rtld lock implementation instead of only when multiple threads > exist. This avoids the sigprocmask() syscalls and should not be much > slower than the default implementation in rtld because that also > contains atomic operations (both the unpatched and the patched version). > People that care about performance of exceptions can then link in libthr > (in many cases, it is already linked in to allow for (the possibility > of) threading). > I have tested this and exceptions were indeed more than twice as fast in > my test program if I created an extra thread doing nothing than in the > fully single-threaded version (with or without libthr). Here is a patch. It is lightly tested. The function _thr_rtld_fini() can be removed afterwards because it is no longer used. Index: lib/libthr/thread/thr_init.c =================================================================== --- lib/libthr/thread/thr_init.c (revision 244639) +++ lib/libthr/thread/thr_init.c (working copy) @@ -363,6 +363,7 @@ _thr_signal_init(); if (_thread_event_mask & TD_CREATE) _thr_report_creation(curthread, curthread); + _thr_rtld_init(); } } Index: lib/libthr/thread/thr_kern.c =================================================================== --- lib/libthr/thread/thr_kern.c (revision 244639) +++ lib/libthr/thread/thr_kern.c (working copy) @@ -57,11 +57,6 @@ return (0); __isthreaded = threaded; - if (threaded != 0) { - _thr_rtld_init(); - } else { - _thr_rtld_fini(); - } return (0); } -- Jilles Tjoelker From owner-freebsd-arch@FreeBSD.ORG Sun Jan 13 13:51:17 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5DEF9B4A; Sun, 13 Jan 2013 13:51:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id AC6306A7; Sun, 13 Jan 2013 13:51:16 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r0DDpAYC042906; Sun, 13 Jan 2013 15:51:10 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r0DDpAYC042906 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r0DDpAKQ042905; Sun, 13 Jan 2013 15:51:10 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 13 Jan 2013 15:51:10 +0200 From: Konstantin Belousov To: Jilles Tjoelker Subject: Re: Fast sigblock (AKA rtld speedup) Message-ID: <20130113135110.GS2561@kib.kiev.ua> References: <20130107182235.GA65279@kib.kiev.ua> <20130111095459.GZ2561@kib.kiev.ua> <50EFE830.3030500@freebsd.org> <20130111204938.GD2561@kib.kiev.ua> <20130111232906.GA29017@stack.nl> <20130112053147.GH2561@kib.kiev.ua> <20130112162547.GA54954@stack.nl> <20130113133159.GA72462@stack.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uc+LCsvbRhlIZa01" Content-Disposition: inline In-Reply-To: <20130113133159.GA72462@stack.nl> User-Agent: Mutt/1.5.21 (2010-09-15) 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 version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: arch@freebsd.org, davidxu@freebsd.org, toolchain@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 13:51:17 -0000 --uc+LCsvbRhlIZa01 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 13, 2013 at 02:32:00PM +0100, Jilles Tjoelker wrote: > On Sat, Jan 12, 2013 at 05:25:47PM +0100, Jilles Tjoelker wrote: > > This suggests a different rather simpler change. Libthr can always use > > its rtld lock implementation instead of only when multiple threads > > exist. This avoids the sigprocmask() syscalls and should not be much > > slower than the default implementation in rtld because that also > > contains atomic operations (both the unpatched and the patched version). > > People that care about performance of exceptions can then link in libthr > > (in many cases, it is already linked in to allow for (the possibility > > of) threading). >=20 > > I have tested this and exceptions were indeed more than twice as fast in > > my test program if I created an extra thread doing nothing than in the > > fully single-threaded version (with or without libthr). >=20 > Here is a patch. It is lightly tested. >=20 > The function _thr_rtld_fini() can be removed afterwards because it is no > longer used. >=20 > Index: lib/libthr/thread/thr_init.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- lib/libthr/thread/thr_init.c (revision 244639) > +++ lib/libthr/thread/thr_init.c (working copy) > @@ -363,6 +363,7 @@ > _thr_signal_init(); > if (_thread_event_mask & TD_CREATE) > _thr_report_creation(curthread, curthread); > + _thr_rtld_init(); Please add a comment there, describing the reason for initializing threaded rtld locks. > } > } > =20 > Index: lib/libthr/thread/thr_kern.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- lib/libthr/thread/thr_kern.c (revision 244639) > +++ lib/libthr/thread/thr_kern.c (working copy) > @@ -57,11 +57,6 @@ > return (0); > =20 > __isthreaded =3D threaded; > - if (threaded !=3D 0) { > - _thr_rtld_init(); > - } else { > - _thr_rtld_fini(); > - } > return (0); > } I do not object. --uc+LCsvbRhlIZa01 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQ8rvNAAoJEJDCuSvBvK1B2cgP/3syRxWJGr+UxICBCFjzuzTf qNJAC8zs4/ZaGLOaH3iRlQ13OnaR5JPq2PTIr5tImuy9f5/ixW0APcSfVq0fBUkF 68ZmPS7ACXvbclkJKVDJE0vazD+vrQ48Tl2KzeHX7ELVYaJI2yzAr7l/wF+z+Dmh GQu/rTS0J/uxjdSXnBwo53oIM2+boab+333Gvz5eUAY1xabPZBnlCoHqf6lhtFcy bIxVmQYRLix3kbRAyXCOtQvCOfKDSFyV7bi8E5UUSPjigXWSjCWXlzKaKT5xsbK1 tOyKFPObOte1GYkhj9nXe+fukImAsgUUeJlP6+42xGPajMhM41IVog8U6wuIjOB9 6VaXc8U1tr+r9zL4uWD/MW7cIThv/VL3Id8N+A1roIxvB/axJrMx7noGA/r/+89k f6zm4BxymXv100tZ7u7bT8VIDjkp4fpQXZCRdC9Qoqvi7UcfhJ7gxKUbbbOQf5Uo 893ysPRxW7oQpSgYiFyrrYTFL1e5mCEqVzO8PKuEv6BS5tuuPdeK1uRlRKTKrfW0 V1lBTFv7JehlLW6gYqmFyokDdbO/6zQmnUMeQIjtYfX+0xIq8UgiODBn8TsqzqlL F6afbDI+d8/2RrSm0vajSzYYPRoXjkbRwfLHEQ3Lbm1oiH7ifnKv3/3pNUMVACDW 0BKhbXfXmfIK78knovi5 =006m -----END PGP SIGNATURE----- --uc+LCsvbRhlIZa01-- From owner-freebsd-arch@FreeBSD.ORG Sun Jan 13 14:52:51 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B92D6A67; Sun, 13 Jan 2013 14:52:51 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 67D9788D; Sun, 13 Jan 2013 14:52:51 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id r0DEoHV8048391; Sun, 13 Jan 2013 07:50:24 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r0DEoEEO000770; Sun, 13 Jan 2013 07:50:14 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: Fast sigblock (AKA rtld speedup) From: Ian Lepore To: John-Mark Gurney In-Reply-To: <20130112230435.GJ1410@funkthat.com> References: <20130107182235.GA65279@kib.kiev.ua> <50EBAA1F.9070303@freebsd.org> <20130112230435.GJ1410@funkthat.com> Content-Type: text/plain; charset="us-ascii" Date: Sun, 13 Jan 2013 07:50:14 -0700 Message-ID: <1358088614.32417.23.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , arch@freebsd.org, David Xu , toolchain@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 14:52:51 -0000 On Sat, 2013-01-12 at 15:04 -0800, John-Mark Gurney wrote: > David Xu wrote this message on Tue, Jan 08, 2013 at 13:09 +0800: > > and can not be freed until process is exited, the page is doubly > > mapped into in kernel and userland, accessing the shared data > > in kernel has zero overhead though. > > Don't forget that there are arches out there w/ VIVT caches which will > probably eliminate most of the performance benifits if we have the same > page mapped writable in two different virtual addresses.. > Even worse than eliminate the benefits, since multiple mappings with one writable disables caching on the whole page, there can be a big penalty depending on what other data is nearby that suddenly becomes uncacheable. I was initially very interested in the work to read system clocks without a syscall until I realized it was going to suffer from the same problem. -- Ian From owner-freebsd-arch@FreeBSD.ORG Sun Jan 13 15:06:47 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 709DECAA; Sun, 13 Jan 2013 15:06:47 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id F1C73909; Sun, 13 Jan 2013 15:06:46 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r0DF6XjZ050925; Sun, 13 Jan 2013 17:06:33 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r0DF6XjZ050925 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r0DF6Xih050924; Sun, 13 Jan 2013 17:06:33 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 13 Jan 2013 17:06:33 +0200 From: Konstantin Belousov To: Ian Lepore Subject: Re: Fast sigblock (AKA rtld speedup) Message-ID: <20130113150633.GV2561@kib.kiev.ua> References: <20130107182235.GA65279@kib.kiev.ua> <50EBAA1F.9070303@freebsd.org> <20130112230435.GJ1410@funkthat.com> <1358088614.32417.23.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xxgoS+Xwt19NyhFM" Content-Disposition: inline In-Reply-To: <1358088614.32417.23.camel@revolution.hippie.lan> User-Agent: Mutt/1.5.21 (2010-09-15) 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 version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: arch@freebsd.org, John-Mark Gurney , David Xu , toolchain@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 15:06:47 -0000 --xxgoS+Xwt19NyhFM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 13, 2013 at 07:50:14AM -0700, Ian Lepore wrote: > On Sat, 2013-01-12 at 15:04 -0800, John-Mark Gurney wrote: > > David Xu wrote this message on Tue, Jan 08, 2013 at 13:09 +0800: > > > and can not be freed until process is exited, the page is doubly > > > mapped into in kernel and userland, accessing the shared data > > > in kernel has zero overhead though. > >=20 > > Don't forget that there are arches out there w/ VIVT caches which will > > probably eliminate most of the performance benifits if we have the same > > page mapped writable in two different virtual addresses.. > >=20 >=20 > Even worse than eliminate the benefits, since multiple mappings with one > writable disables caching on the whole page, there can be a big penalty > depending on what other data is nearby that suddenly becomes > uncacheable. I was initially very interested in the work to read system > clocks without a syscall until I realized it was going to suffer from > the same problem. Since only kernel writes to the shared page, it should be not a problem. At least there is a specific point where you can insert the neccessary cache flush commands. Also, I suspect that even for arms, the writes are executed from the same core, which could simplify things even more. --xxgoS+Xwt19NyhFM Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQ8s14AAoJEJDCuSvBvK1BgsAP/3I1KlKAMW9MESzj+WJBnKXh 5mhjDWuogY6QN9Cyg03nOcNO5OBLsXBSDB/rWT6qy8zyWqcMpPQ5QJ2y6gktn24L 09Ex6lTUZ8Ej9zIVsLhvdBTUSasr4+GqOEWHFT/iR2WG0PJqmDUwAEOQGHuQ7tq/ 6bmFzlZvFq5UjiBpGOXrr8Ip1j7umbKdYQ5GwZqz2OAxFsQbXEYLPRBhuK5a5mfU Tmtn2iYTethep5ey5cgUj2DfzKxM6cM/YNow0bFefoMPwXZ4taGx1xv+wfcgEs/K RINT3ER7y0t0UtJQFZGBNmX+tTdGCC8v0nHIJI6s98iQu+Pb/Q87E3bXZ+KIoQsf jkP0ENSAIUOmeLs55pt/5REe/e0hXadLr8D43qHUrvCDdKHfJBTKo2ZMSutlDA9g G+9r7PVMIw9egY3V55/l1jZB3szqc8MG6d2I4WgNh3NFXlsL83RhnVwiBhcbXi8k Wn4RLE5/9TpfoBRP4nSOkPEh+rEqVu4GIhsFJSXZ7usiJlxcgnWGSCuMj3M31UKe Vixvqi7+jaHVAzjqpPythaxW/19e2HxX7ZE5ABAMVSqAjYC7BNbf0y7Nr+i765Qj 1wtz7UX19y38GNaHjVbAFYs2Hhm79rjHTqhlZ39u8XSFgTU1MFLPpMXMOgUdCQ7j iRKhKtEVaWRIjPREA7q9 =BbUz -----END PGP SIGNATURE----- --xxgoS+Xwt19NyhFM-- From owner-freebsd-arch@FreeBSD.ORG Sun Jan 13 16:21:40 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 65F8FAC7; Sun, 13 Jan 2013 16:21:40 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from agogare.doit.wisc.edu (agogare.doit.wisc.edu [144.92.197.211]) by mx1.freebsd.org (Postfix) with ESMTP id 3FF39D80; Sun, 13 Jan 2013 16:21:40 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from avs-daemon.smtpauth2.wiscmail.wisc.edu by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0MGK00300O432900@smtpauth2.wiscmail.wisc.edu>; Sun, 13 Jan 2013 10:21:39 -0600 (CST) Received: from wanderer.tachypleus.net (c-24-63-204-107.hsd1.ct.comcast.net [24.63.204.107]) by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0MGK000KJO413W10@smtpauth2.wiscmail.wisc.edu>; Sun, 13 Jan 2013 10:21:38 -0600 (CST) Date: Sun, 13 Jan 2013 08:21:37 -0800 From: Nathan Whitehorn Subject: Re: LLVM Image Activator In-reply-to: <20130113132057.GQ2561@kib.kiev.ua> Sender: whitehorn@wisc.edu To: Konstantin Belousov Message-id: <50F2DF11.50202@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=24.63.204.107 X-Spam-PmxInfo: Server=avs-15, Version=5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.1.13.161217, SenderIP=24.63.204.107 References: <50E9BC2D.7000302@freebsd.org> <201301070936.39052.jhb@freebsd.org> <20130107172433.GX82219@kib.kiev.ua> <20130113132057.GQ2561@kib.kiev.ua> User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130112 Thunderbird/17.0.2 Cc: Ed Schouten , freebsd-toolchain@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 16:21:40 -0000 On 01/13/13 05:20, Konstantin Belousov wrote: > On Sun, Jan 13, 2013 at 12:41:09PM +0100, Ed Schouten wrote: >> Hi Kostik, >> >> 2013/1/7 Konstantin Belousov : >>> I still do remember the buzz about the binary format 0xCAFEBABE, which >>> AFAIR gained image activator support on several OSes, to be garbage >>> collected. >> >> Maybe it would then be a good idea then to add some kind of general >> purpose remapping imgact? Example: >> >> /etc/imgacttab: >> >> cafebabe /usr/local/bin/java >> cffaedfe /usr/local/bin/osx_emulator >> 4243c0de /usr/bin/lli >> >> That way we still give people the freedom to play around with mapping >> their own executable formats, but don't need to maintain a bunch of >> imgacts. > > A generic module that could be somewhat customized at runtime to map > offset+signature into the shebang path could be a possibility indeed. > I strongly prefer to have it as module and not enabled by default. > > Asking Nathan for writing the thing is too much, IMHO, esp. in > the response to the 50-lines hack. > I think this is a good idea, since it both prevents a profusion of similar activators and works nicely in jails and similar environments. I probably won't write it quickly, but it should not take more than about 50 lines, so I can't imagine it will be that bad. There are some complications with this kind of design from the things in the XXX comment in imgact_llvm.c about handling argv[0] that I need to think some more about. Why are you opposed to having it there by default? I think it's actually quite important that it be there by default. Having it not "standard" would be fine, but it should at least be in GENERIC. There are minimal security risks since it just munges begin_argv and doesn't even load the executable and it's little enough code that there should not be any kernel bloat to speak of. If things like this aren't enabled by default, no one can depend on them being there, no one will use it, and the point is entirely lost. -Nathan From owner-freebsd-arch@FreeBSD.ORG Sun Jan 13 17:13:14 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3A8FB4C1; Sun, 13 Jan 2013 17:13:14 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 8B36BFB6; Sun, 13 Jan 2013 17:13:13 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r0DHD48o068424; Sun, 13 Jan 2013 19:13:04 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r0DHD48o068424 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r0DHD4HF068423; Sun, 13 Jan 2013 19:13:04 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 13 Jan 2013 19:13:04 +0200 From: Konstantin Belousov To: Nathan Whitehorn Subject: Re: LLVM Image Activator Message-ID: <20130113171304.GZ2561@kib.kiev.ua> References: <50E9BC2D.7000302@freebsd.org> <201301070936.39052.jhb@freebsd.org> <20130107172433.GX82219@kib.kiev.ua> <20130113132057.GQ2561@kib.kiev.ua> <50F2DF11.50202@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GEbvMeJjk36GUqgv" Content-Disposition: inline In-Reply-To: <50F2DF11.50202@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) 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 version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Ed Schouten , freebsd-toolchain@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 17:13:14 -0000 --GEbvMeJjk36GUqgv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 13, 2013 at 08:21:37AM -0800, Nathan Whitehorn wrote: > On 01/13/13 05:20, Konstantin Belousov wrote: > > On Sun, Jan 13, 2013 at 12:41:09PM +0100, Ed Schouten wrote: > >> Hi Kostik, > >> > >> 2013/1/7 Konstantin Belousov : > >>> I still do remember the buzz about the binary format 0xCAFEBABE, which > >>> AFAIR gained image activator support on several OSes, to be garbage > >>> collected. > >> > >> Maybe it would then be a good idea then to add some kind of general > >> purpose remapping imgact? Example: > >> > >> /etc/imgacttab: > >> > >> cafebabe /usr/local/bin/java > >> cffaedfe /usr/local/bin/osx_emulator > >> 4243c0de /usr/bin/lli > >> > >> That way we still give people the freedom to play around with mapping > >> their own executable formats, but don't need to maintain a bunch of > >> imgacts. > >=20 > > A generic module that could be somewhat customized at runtime to map > > offset+signature into the shebang path could be a possibility indeed. > > I strongly prefer to have it as module and not enabled by default. > >=20 > > Asking Nathan for writing the thing is too much, IMHO, esp. in > > the response to the 50-lines hack. > >=20 >=20 > I think this is a good idea, since it both prevents a profusion of > similar activators and works nicely in jails and similar environments. I > probably won't write it quickly, but it should not take more than about > 50 lines, so I can't imagine it will be that bad. There are some > complications with this kind of design from the things in the XXX > comment in imgact_llvm.c about handling argv[0] that I need to think > some more about. Great. I do not believe in the 50 lines, but I am happy that you want to work this out. >=20 > Why are you opposed to having it there by default? I think it's actually > quite important that it be there by default. Having it not "standard" > would be fine, but it should at least be in GENERIC. There are minimal > security risks since it just munges begin_argv and doesn't even load the > executable and it's little enough code that there should not be any > kernel bloat to speak of. If things like this aren't enabled by default, > no one can depend on them being there, no one will use it, and the point > is entirely lost. All image activators demonstrated a constant stream of security holes. Even our ELF activator, and I was guilty there too. I definitely do not fight over the inclusion of the proposed activator into GENERIC, but do insist on the config option + module. --GEbvMeJjk36GUqgv Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQ8usfAAoJEJDCuSvBvK1B7ZEP/3kcYy5fF7Ld9YBfRAwqMaBu IpEiPPpKtK2KarELSvRXTIYIoy92kJE5ax7Ad+cummm3sNN2yolBQAKJ+fAkHnBv +hWLpKxOmzdnjw4fO0GLU71vNEImTtj8YSymErZxNl10HTrwl8usBkl0SlequI11 m5fbbNNmsBK+6TS9OP/6CN9Pq1exqUPsu4HUDUunFJ+ucOAcCh4tNddcTRZwItc9 wMYErq+XWhd7t29g0PyAH3Tw9h9MgvKPGNrRUzji/Ytno5sv9Xg0ZBQ/MP3PLt4i kulsU3Nvko32YGl/Kme7Kl3jU2sGEq0p9S1IIPqbmyVxd49/3w7pW9SSFffoijPX S+R5MCEKQo3cGvyAEawa0hxaCY84KZd5njGfNN6FQtThwjZMY8bfFNWqAKpbNRmI bXt+sNipZu8vJnEa2NNjr8CtpShvoczkxNMGHVU+ZWiG81QekqdaH8yRSAsgRGB9 T4s0cQTXoI4GmX8Zl6u9p1yFVQ5bS3zs4oCbRUme5zsqHX1L7ufNUl6F8TayELvX 46YOhiuWZIShvI/oRU1MZcgVq6VZy/eElf8WbiiNDKZVyI9VsfJRm6x+b2KM9OlC KdGV4aUDaesjAkk5KQCS118vxZDvtSY7lyksSlN1UqFqq4G+tQi2Ch4I+FvqLV5d kEsyiEh666KnTaWUAZI4 =Xf2/ -----END PGP SIGNATURE----- --GEbvMeJjk36GUqgv-- From owner-freebsd-arch@FreeBSD.ORG Sun Jan 13 17:46:32 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E4BEE987; Sun, 13 Jan 2013 17:46:32 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 71FDDFA; Sun, 13 Jan 2013 17:46:31 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id r0DHkUEu058107; Sun, 13 Jan 2013 10:46:30 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r0DHkROi000960; Sun, 13 Jan 2013 10:46:28 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: Fast sigblock (AKA rtld speedup) From: Ian Lepore To: Konstantin Belousov In-Reply-To: <20130113150633.GV2561@kib.kiev.ua> References: <20130107182235.GA65279@kib.kiev.ua> <50EBAA1F.9070303@freebsd.org> <20130112230435.GJ1410@funkthat.com> <1358088614.32417.23.camel@revolution.hippie.lan> <20130113150633.GV2561@kib.kiev.ua> Content-Type: text/plain; charset="us-ascii" Date: Sun, 13 Jan 2013 10:46:27 -0700 Message-ID: <1358099187.32417.31.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, John-Mark Gurney , David Xu , toolchain@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 17:46:33 -0000 On Sun, 2013-01-13 at 17:06 +0200, Konstantin Belousov wrote: > On Sun, Jan 13, 2013 at 07:50:14AM -0700, Ian Lepore wrote: > > On Sat, 2013-01-12 at 15:04 -0800, John-Mark Gurney wrote: > > > David Xu wrote this message on Tue, Jan 08, 2013 at 13:09 +0800: > > > > and can not be freed until process is exited, the page is doubly > > > > mapped into in kernel and userland, accessing the shared data > > > > in kernel has zero overhead though. > > > > > > Don't forget that there are arches out there w/ VIVT caches which will > > > probably eliminate most of the performance benifits if we have the same > > > page mapped writable in two different virtual addresses.. > > > > > > > Even worse than eliminate the benefits, since multiple mappings with one > > writable disables caching on the whole page, there can be a big penalty > > depending on what other data is nearby that suddenly becomes > > uncacheable. I was initially very interested in the work to read system > > clocks without a syscall until I realized it was going to suffer from > > the same problem. > > Since only kernel writes to the shared page, it should be not a problem. > At least there is a specific point where you can insert the neccessary > cache flush commands. With VIVT cache, all mappings of a page must be uncacheable no matter which one is writable. It applies even if all the mappings belong to the kernel (this is why the wired writable pages in the buffer cache kill executable performance with VIVT caches). There's no way to keep a VIVT cache coherent when there are multiple mappings, because of the virtual indexing: you write to a page, then do a flush based on that page's virtual address, and there's no way find cache lines which alias the same physical memory using different virtual addresses to flush them too. > Also, I suspect that even for arms, the writes are executed from the > same core, which could simplify things even more. The arm chips that are affected by this don't have multiple cores (at least, I don't think there are any VIVT cache multi-core arms, it's probably not even possible). -- Ian From owner-freebsd-arch@FreeBSD.ORG Sun Jan 13 17:50:43 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 83F6DAB8; Sun, 13 Jan 2013 17:50:43 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id D3151131; Sun, 13 Jan 2013 17:50:42 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r0DHoTNB072616; Sun, 13 Jan 2013 19:50:29 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r0DHoTNB072616 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r0DHoTb5072615; Sun, 13 Jan 2013 19:50:29 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 13 Jan 2013 19:50:29 +0200 From: Konstantin Belousov To: Ian Lepore Subject: Re: Fast sigblock (AKA rtld speedup) Message-ID: <20130113175029.GA2561@kib.kiev.ua> References: <20130107182235.GA65279@kib.kiev.ua> <50EBAA1F.9070303@freebsd.org> <20130112230435.GJ1410@funkthat.com> <1358088614.32417.23.camel@revolution.hippie.lan> <20130113150633.GV2561@kib.kiev.ua> <1358099187.32417.31.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Qcw+NG9yjQzXdZsc" Content-Disposition: inline In-Reply-To: <1358099187.32417.31.camel@revolution.hippie.lan> User-Agent: Mutt/1.5.21 (2010-09-15) 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 version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: arch@freebsd.org, John-Mark Gurney , David Xu , toolchain@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 17:50:43 -0000 --Qcw+NG9yjQzXdZsc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 13, 2013 at 10:46:27AM -0700, Ian Lepore wrote: > On Sun, 2013-01-13 at 17:06 +0200, Konstantin Belousov wrote: > > On Sun, Jan 13, 2013 at 07:50:14AM -0700, Ian Lepore wrote: > > > On Sat, 2013-01-12 at 15:04 -0800, John-Mark Gurney wrote: > > > > David Xu wrote this message on Tue, Jan 08, 2013 at 13:09 +0800: > > > > > and can not be freed until process is exited, the page is doubly > > > > > mapped into in kernel and userland, accessing the shared data > > > > > in kernel has zero overhead though. > > > >=20 > > > > Don't forget that there are arches out there w/ VIVT caches which w= ill > > > > probably eliminate most of the performance benifits if we have the = same > > > > page mapped writable in two different virtual addresses.. > > > >=20 > > >=20 > > > Even worse than eliminate the benefits, since multiple mappings with = one > > > writable disables caching on the whole page, there can be a big penal= ty > > > depending on what other data is nearby that suddenly becomes > > > uncacheable. I was initially very interested in the work to read sys= tem > > > clocks without a syscall until I realized it was going to suffer from > > > the same problem. > >=20 > > Since only kernel writes to the shared page, it should be not a problem. > > At least there is a specific point where you can insert the neccessary > > cache flush commands. >=20 > With VIVT cache, all mappings of a page must be uncacheable no matter > which one is writable. It applies even if all the mappings belong to > the kernel (this is why the wired writable pages in the buffer cache > kill executable performance with VIVT caches). >=20 > There's no way to keep a VIVT cache coherent when there are multiple > mappings, because of the virtual indexing: you write to a page, then do > a flush based on that page's virtual address, and there's no way find > cache lines which alias the same physical memory using different virtual > addresses to flush them too. No, you do know all the mapping addresses in this special case. The shared page is mapped at the fixed user address, and at some kernel address. You obviously need to flush both cache lines. >=20 > > Also, I suspect that even for arms, the writes are executed from the > > same core, which could simplify things even more. >=20 > The arm chips that are affected by this don't have multiple cores (at > least, I don't think there are any VIVT cache multi-core arms, it's > probably not even possible). >=20 > -- Ian >=20 --Qcw+NG9yjQzXdZsc Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQ8vPkAAoJEJDCuSvBvK1BPwcP/2J8EpvsPnYRVj9X//KIpxb2 J7a48lmejktht9W7esIMWnBhrYl4bQCWTZuwnffqEwLlTCt5VsHwc1NGfDoigeV2 LQCiFuG/rSkTNpBDBJdNDDxTOmK+wLU6eLck9gj0INtgM7bVQUuP05gfU9utSjvG hCmLIN4nzkiSR9mSZWeJ7n2qq1Qy6k18dT2q68TAiXAscn3uuHxIJXmwLoahLrbb xlxorirXWn62lPFD9VPf0gRW98JzphKY/0oXseI/PhZjKD8ZpoPbnr9kmu1FrBZX Jtezg9eGHd3kH6KGdh1CZ9dxaR54MLcJDQCgN6bxWoJw6BO4hkclq/T6rWpvxOKh 8bXkS8OLsLCH3YYML01PEJtcf6bvkQ3CxuBt+apmkSpVDtRrel0SrT3S9xxPDUQc HD3agGo5FUthJnQzMhqpUHi4S3itA+Gk+3b26Wfza0RIJFp0lXPZ04dXq7RjfiPx B/EEWZb0/GU60OOUH+FoWp6q1jnhrzaOdJcs8pN8TmqpVnXL3z9ErGeOO4rZYspw 2YLYOfB1fpH4mcejqPyEbeSdp1XjUhq3h2CRHVQGjWk0dynosvCnekW/IXsxb4ev OwxUL8NKR3LBj2pnnqbAShB1t+yw3kknl1wuP4ytIaccpAQqizx/sHbw7eDql/ev LP3E/y31ymppF3lj16gz =GCvl -----END PGP SIGNATURE----- --Qcw+NG9yjQzXdZsc-- From owner-freebsd-arch@FreeBSD.ORG Sun Jan 13 17:53:22 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 30DECBAE; Sun, 13 Jan 2013 17:53:22 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id F3056158; Sun, 13 Jan 2013 17:53:21 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id r0DHrL7C058501; Sun, 13 Jan 2013 10:53:21 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r0DHrIGw000975; Sun, 13 Jan 2013 10:53:18 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: Fast sigblock (AKA rtld speedup) From: Ian Lepore To: Konstantin Belousov In-Reply-To: <20130113175029.GA2561@kib.kiev.ua> References: <20130107182235.GA65279@kib.kiev.ua> <50EBAA1F.9070303@freebsd.org> <20130112230435.GJ1410@funkthat.com> <1358088614.32417.23.camel@revolution.hippie.lan> <20130113150633.GV2561@kib.kiev.ua> <1358099187.32417.31.camel@revolution.hippie.lan> <20130113175029.GA2561@kib.kiev.ua> Content-Type: text/plain; charset="us-ascii" Date: Sun, 13 Jan 2013 10:53:18 -0700 Message-ID: <1358099598.32417.33.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, John-Mark Gurney , David Xu , toolchain@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 17:53:22 -0000 On Sun, 2013-01-13 at 19:50 +0200, Konstantin Belousov wrote: > On Sun, Jan 13, 2013 at 10:46:27AM -0700, Ian Lepore wrote: > > On Sun, 2013-01-13 at 17:06 +0200, Konstantin Belousov wrote: > > > On Sun, Jan 13, 2013 at 07:50:14AM -0700, Ian Lepore wrote: > > > > On Sat, 2013-01-12 at 15:04 -0800, John-Mark Gurney wrote: > > > > > David Xu wrote this message on Tue, Jan 08, 2013 at 13:09 +0800: > > > > > > and can not be freed until process is exited, the page is doubly > > > > > > mapped into in kernel and userland, accessing the shared data > > > > > > in kernel has zero overhead though. > > > > > > > > > > Don't forget that there are arches out there w/ VIVT caches which will > > > > > probably eliminate most of the performance benifits if we have the same > > > > > page mapped writable in two different virtual addresses.. > > > > > > > > > > > > > Even worse than eliminate the benefits, since multiple mappings with one > > > > writable disables caching on the whole page, there can be a big penalty > > > > depending on what other data is nearby that suddenly becomes > > > > uncacheable. I was initially very interested in the work to read system > > > > clocks without a syscall until I realized it was going to suffer from > > > > the same problem. > > > > > > Since only kernel writes to the shared page, it should be not a problem. > > > At least there is a specific point where you can insert the neccessary > > > cache flush commands. > > > > With VIVT cache, all mappings of a page must be uncacheable no matter > > which one is writable. It applies even if all the mappings belong to > > the kernel (this is why the wired writable pages in the buffer cache > > kill executable performance with VIVT caches). > > > > There's no way to keep a VIVT cache coherent when there are multiple > > mappings, because of the virtual indexing: you write to a page, then do > > a flush based on that page's virtual address, and there's no way find > > cache lines which alias the same physical memory using different virtual > > addresses to flush them too. > No, you do know all the mapping addresses in this special case. > > The shared page is mapped at the fixed user address, and at some > kernel address. You obviously need to flush both cache lines. > > > > > > Also, I suspect that even for arms, the writes are executed from the > > > same core, which could simplify things even more. > > > > The arm chips that are affected by this don't have multiple cores (at > > least, I don't think there are any VIVT cache multi-core arms, it's > > probably not even possible). > > > > -- Ian > > But as soon as you establish the second mapping, the code in pmap.c automatically remaps all existing mappings as uncacheable. It would be some pretty big work to special-case that for a few mappings where the kernel "knows what it's doing." -- ian From owner-freebsd-arch@FreeBSD.ORG Sun Jan 13 18:06:32 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 04EA4F0C; Sun, 13 Jan 2013 18:06:32 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id C16961DF; Sun, 13 Jan 2013 18:06:31 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (unknown [207.238.187.242]) by elvis.mu.org (Postfix) with ESMTPSA id 3E2691A3C52; Sun, 13 Jan 2013 10:06:21 -0800 (PST) Message-ID: <50F2F79C.7040109@mu.org> Date: Sun, 13 Jan 2013 13:06:20 -0500 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: svn commit: r243631 - in head/sys: kern sys References: <201211272119.qARLJxXV061083@svn.freebsd.org> <50C1BC90.90106@freebsd.org> <50C25A27.4060007@bluezbox.com> <50C26331.6030504@freebsd.org> <50C26AE9.4020600@bluezbox.com> <50C3A3D3.9000804@freebsd.org> <50C3AF72.4010902@rice.edu> <330405A1-312A-45A5-BB86-4969478D8BBD@bluezbox.com> <50D03E83.8060908@rice.edu> <50DD081E.8000409@bluezbox.com> <50EB1841.5030006@bluezbox.com> <50EB22D2.6090103@rice.edu> <50EB415F.8020405@freebsd.org> <50F04FE5.7010406@rice.edu> <50F1BD69.4060104@mu.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: src-committers@freebsd.org, Andre Oppermann , Alan Cox , "Jayachandran C." , svn-src-all@freebsd.org, Oleksandr Tymoshenko , freebsd-arch@freebsd.org, svn-src-head@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 18:06:32 -0000 On 1/12/13 10:32 PM, Adrian Chadd wrote: > On 12 January 2013 11:45, Alfred Perlstein wrote: > >> I'm not sure if regressing to the waterfall method of development is a good >> idea at this point. >> >> I see a light at the end of the tunnel and we to continue to just handle >> these minor corner cases as we progress. >> >> If we move to a model where a minor bug is grounds to completely remove >> helpful code then nothing will ever get done. >> > Allocating 512MB worth of callwheels on a 16GB MIPS machine is a > little silly, don't you think? > > That suggests to me that the extent of which maxfiles/maxusers/etc > percolates the codebase wasn't totally understood by those who wish to > change it. > > I'd rather see some more investigative work into outlining things that > need fixing and start fixing those, rather than "just change stuff and > fix whatever issues creep up." > > I kinda hope we all understand what we're working on in the kernel a > little better than that. Cool! I'm glad people are now aware of the callwheel allocation being insane with large maxusers. I saw this about a month ago (if not longer), but since there were half a dozen people calling me an imbecile who hadn't really yet read the code I didn't want to inflame them more by fixing that with "a hack". (actually a simple fix). A simple fix is to clamp callwheel size to the previous result of a maxusers of 384 and call it a day. However the simplicity of that approach would probably inflame too many feelings so I am unsure as how to proceed. Any ideas? -Alfred From owner-freebsd-arch@FreeBSD.ORG Sun Jan 13 18:09:42 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5E1BB202; Sun, 13 Jan 2013 18:09:42 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 04201205; Sun, 13 Jan 2013 18:09:41 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.5/8.14.5/ALCHEMY.FRANKEN.DE) with ESMTP id r0DI9enr013768; Sun, 13 Jan 2013 19:09:40 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.5/8.14.5/Submit) id r0DI9eUL013767; Sun, 13 Jan 2013 19:09:40 +0100 (CET) (envelope-from marius) Date: Sun, 13 Jan 2013 19:09:40 +0100 From: Marius Strobl To: Alexander Motin Subject: Re: [RFC/RFT] calloutng Message-ID: <20130113180940.GM26039@alchemy.franken.de> References: <50CCAB99.4040308@FreeBSD.org> <50CE5B54.3050905@FreeBSD.org> <50D03173.9080904@FreeBSD.org> <20121225232126.GA47692@alchemy.franken.de> <50DB4EFE.2020600@FreeBSD.org> <20130106152313.GD26039@alchemy.franken.de> <50EBF921.2000304@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50EBF921.2000304@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Davide Italiano , FreeBSD Current , freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 18:09:42 -0000 On Tue, Jan 08, 2013 at 12:46:57PM +0200, Alexander Motin wrote: > On 06.01.2013 17:23, Marius Strobl wrote: > > On Wed, Dec 26, 2012 at 09:24:46PM +0200, Alexander Motin wrote: > >> On 26.12.2012 01:21, Marius Strobl wrote: > >>> On Tue, Dec 18, 2012 at 11:03:47AM +0200, Alexander Motin wrote: > >>>> Experiments with dummynet shown ineffective support for very short > >>>> tick-based callouts. New version fixes that, allowing to get as many > >>>> tick-based callout events as hz value permits, while still be able to > >>>> aggregate events and generating minimum of interrupts. > >>>> > >>>> Also this version modifies system load average calculation to fix some > >>>> cases existing in HEAD and 9 branches, that could be fixed with new > >>>> direct callout functionality. > >>>> > >>>> http://people.freebsd.org/~mav/calloutng_12_17.patch > >>>> > >>>> With several important changes made last time I am going to delay commit > >>>> to HEAD for another week to do more testing. Comments and new test cases > >>>> are welcome. Thanks for staying tuned and commenting. > >>> > >>> FYI, I gave both calloutng_12_15_1.patch and calloutng_12_17.patch a > >>> try on sparc64 and it at least survives a buildworld there. However, > >>> with the patched kernels, buildworld times seem to increase slightly but > >>> reproducible by 1-2% (I only did four runs but typically buildworld > >>> times are rather stable and don't vary more than a minute for the > >>> same kernel and source here). Is this an expected trade-off (system > >>> time as such doesn't seem to increase)? > >> > >> I don't think build process uses significant number of callouts to > >> affect results directly. I think this additional time could be result of > >> the deeper next event look up, done by the new code, that is practically > >> useless for sparc64, which effectively has no cpu_idle() routine. It > >> wouldn't affect system time and wouldn't show up in any statistics > >> (except PMC or something alike) because it is executed inside timer > >> hardware interrupt handler. If my guess is right, that is a part that > >> probably still could be optimized. I'll look on it. Thanks. > >> > >>> Is there anything specific to test? > >> > >> Since the most of code is MI, for sparc64 I would mostly look on related > >> MD parts (eventtimers and timecounters) to make sure they are working > >> reliably in more stressful conditions. I still have some worries about > >> possible deadlock on hardware where IPIs are used to fetch present time > >> from other CPU. > > > > Well, I've just learnt two things the hard way: > > a) We really need the mutex in that path. > > b) Assuming that the initial synchronization of the counters is good > > enough and they won't drift considerably accross the CPUs so we can > > always use the local one makes things go south pretty soon after > > boot. At least with your calloutng_12_26.patch applied. > > Do you think it means they are not really synchronized for some reason? There's definitely no hardware in place which would synchronize them. I've no idea how to properly measure the difference between two tick counters, but I think it's rarther their drift and not the software synchronization we do when starting APs that is causing problems. Mainly, because I can't really think of a better algorithm for doing the latter when startiing the APs. The symptoms are that bout 30 to 60 seconds after that I start to see weird timeouts from device drivers. I'd need to check how long these timeouts actually are to see whether it could be a problem right from the start though. In any case, it seems foolish to think that synchronizing them once would be sufficient and they won't drift until shutdown. Linux probably also doesn't keep re-synchronize them without a reason. Just using a single timecounter source simply appears to be the better choice. > > > I'm not really sure what to do about that. Earlier you already said > > that sched_bind(9) also isn't an option in case if td_critnest > 1. > > To be honest, I don't really unerstand why using a spin lock in the > > timecounter path makes sparc64 the only problematic architecture > > for your changes. The x86 i8254_get_timecount() also uses a spin lock > > so it should be in the same boat. > > The problem is not in using spinlock, but in waiting for other CPU while > spinlock is held. Other CPU may also hold spinlock and wait for > something, causing deadlock. i8254 code uses spinlock just to atomically > access hardware registers, so it causes no problems. Okay, but wouldn't that be a general problem then? Pretty much anything triggering an IPI holds smp_ipi_mtx while doing so and the lower level IPI stuff waits for other CPU(s), including on x86. > > > The affected machines are equipped with a x86-style south bridge > > which exposes a powermanagment unit (intended to be used as a SMBus > > bridge only in these machines) on the PCI bus. Actually, this device > > also includes an ACPI power management timer. However, I've just > > spent a day trying to get that one working without success - it > > just doesn't increment. Probably its clock input isn't connected as > > it's not intended to be used in these machines. > > That south bridge also includes 8254 compatible timers on the ISA/ > > LPC side, but are hidden from the OFW device tree. I can hack these > > devices into existence and give it a try, but even if that works this > > likely would use the same code as the x86 i8254_get_timecount() so I > > don't see what would be gained with that. > > > > The last thing in order to avoid using the tick counter as timecounter > > in the MP case I can think of is that the Broadcom MACs in the affected > > machines also provide a counter driven by a 1 MHz clock. If that's good > > enough for a timecounter I can hook these up (in case these work ...) > > and hack bge(4) to not detach in that case (given that we can't detach > > timecounters ...). > > i8254 on x86 is also just a bit above 1MHz. > > >> Here is small tool we are using for test correctness and performance of > >> different user-level APIs: http://people.freebsd.org/~mav/testsleep.c > >> > > > > I've run Ian's set of tests on a v215 with and without your > > calloutng_12_26.patch and on a v210 (these uses the IPI approach) > > with the latter also applied. > > I'm not really sure what to make out of the numbers. > > > > v215 w/o v215 w/ v210 w/ > > ---------- ---------------- ---------------- ---------------- > > select 1 1999.61 1 23.87 1 29.97 > > poll 1 1999.70 1 1069.61 1 1075.24 > > usleep 1 1999.86 1 23.43 1 28.99 > > nanosleep 1 999.92 1 23.28 1 28.66 > > kqueue 1 1000.12 1 1071.13 1 1076.35 > > kqueueto 1 999.56 1 26.33 1 31.34 > > syscall 1 1.89 1 1.92 1 2.88 FYI, these are the results of the v215 (btw., these (ab)use a bus cycle counter of the host-PCI-bridge as timecounter) with your calloutng_12_17.patch and kern.timecounter.alloweddeviation=0: select 1 23.82 poll 1 1008.23 usleep 1 23.31 nanosleep 1 23.17 kqueue 1 1010.35 kqueueto 1 26.26 syscall 1 1.91 select 300 307.72 poll 300 1008.23 usleep 300 307.64 nanosleep 300 23.21 kqueue 300 1010.49 kqueueto 300 26.27 syscall 300 1.92 select 3000 3009.95 poll 3000 3013.33 usleep 3000 3013.56 nanosleep 3000 23.17 kqueue 3000 3011.09 kqueueto 3000 26.24 syscall 3000 1.91 select 30000 30013.51 poll 30000 30010.63 usleep 30000 30010.64 nanosleep 30000 36.91 kqueue 30000 30012.38 kqueueto 30000 39.90 syscall 30000 1.90 select 300000 300017.52 poll 300000 300013.00 usleep 300000 300012.64 nanosleep 300000 307.59 kqueue 300000 300017.07 kqueueto 300000 310.24 syscall 300000 1.93 > > Numbers are not bad, respecting the fact that to protect from lost > interrupts eventtimer code on sparc64 now sets minimal programming > interval to 15us. It was made to reduce race window between the timer > read-modify-write and some long NMIs. Uhm, there are no NMIs on sparc64. Does it make sense to bypass this adjustment on sparc64? > May be with rereading counter > after programming comparator (same as done for HPET, reading which is > probably much more expensive) this value could be reduced. > I see. There are some bigger fish to fry at the moment though :) Marius From owner-freebsd-arch@FreeBSD.ORG Sun Jan 13 18:14:22 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E7C94631; Sun, 13 Jan 2013 18:14:22 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from argol.doit.wisc.edu (argol.doit.wisc.edu [144.92.197.212]) by mx1.freebsd.org (Postfix) with ESMTP id C35D2274; Sun, 13 Jan 2013 18:14:22 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from wanderer.tachypleus.net (c-24-63-204-107.hsd1.ct.comcast.net [24.63.204.107]) by smtpauth3.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0MGK006GVTBV7J00@smtpauth3.wiscmail.wisc.edu>; Sun, 13 Jan 2013 12:14:22 -0600 (CST) X-Spam-PmxInfo: Server=avs-3, Version=5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.1.13.180328, SenderIP=24.63.204.107 X-Spam-Report: AuthenticatedSender=yes, SenderIP=24.63.204.107 X-Wisc-Sender: whitehorn@wisc.edu Message-id: <50F2F97B.5030306@freebsd.org> Date: Sun, 13 Jan 2013 10:14:19 -0800 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130112 Thunderbird/17.0.2 To: Konstantin Belousov Subject: Re: LLVM Image Activator References: <50E9BC2D.7000302@freebsd.org> <201301070936.39052.jhb@freebsd.org> <20130107172433.GX82219@kib.kiev.ua> <20130113132057.GQ2561@kib.kiev.ua> <50F2DF11.50202@freebsd.org> <20130113171304.GZ2561@kib.kiev.ua> In-reply-to: <20130113171304.GZ2561@kib.kiev.ua> Cc: Ed Schouten , freebsd-toolchain@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 18:14:23 -0000 On 01/13/13 09:13, Konstantin Belousov wrote: > On Sun, Jan 13, 2013 at 08:21:37AM -0800, Nathan Whitehorn wrote: >> On 01/13/13 05:20, Konstantin Belousov wrote: >>> On Sun, Jan 13, 2013 at 12:41:09PM +0100, Ed Schouten wrote: >>>> Hi Kostik, >>>> >>>> 2013/1/7 Konstantin Belousov : >>>>> I still do remember the buzz about the binary format 0xCAFEBABE, which >>>>> AFAIR gained image activator support on several OSes, to be garbage >>>>> collected. >>>> >>>> Maybe it would then be a good idea then to add some kind of general >>>> purpose remapping imgact? Example: >>>> >>>> /etc/imgacttab: >>>> >>>> cafebabe /usr/local/bin/java >>>> cffaedfe /usr/local/bin/osx_emulator >>>> 4243c0de /usr/bin/lli >>>> >>>> That way we still give people the freedom to play around with mapping >>>> their own executable formats, but don't need to maintain a bunch of >>>> imgacts. >>> >>> A generic module that could be somewhat customized at runtime to map >>> offset+signature into the shebang path could be a possibility indeed. >>> I strongly prefer to have it as module and not enabled by default. >>> >>> Asking Nathan for writing the thing is too much, IMHO, esp. in >>> the response to the 50-lines hack. >>> >> >> I think this is a good idea, since it both prevents a profusion of >> similar activators and works nicely in jails and similar environments. I >> probably won't write it quickly, but it should not take more than about >> 50 lines, so I can't imagine it will be that bad. There are some >> complications with this kind of design from the things in the XXX >> comment in imgact_llvm.c about handling argv[0] that I need to think >> some more about. > Great. I do not believe in the 50 lines, but I am happy that you want > to work this out. > >> >> Why are you opposed to having it there by default? I think it's actually >> quite important that it be there by default. Having it not "standard" >> would be fine, but it should at least be in GENERIC. There are minimal >> security risks since it just munges begin_argv and doesn't even load the >> executable and it's little enough code that there should not be any >> kernel bloat to speak of. If things like this aren't enabled by default, >> no one can depend on them being there, no one will use it, and the point >> is entirely lost. > All image activators demonstrated a constant stream of security holes. > Even our ELF activator, and I was guilty there too. > > I definitely do not fight over the inclusion of the proposed activator > into GENERIC, but do insist on the config option + module. > OK, that sounds like a plan then. I'll try to code up something configurable in the next couple weeks, unless someone else beats me to it. -Nathan From owner-freebsd-arch@FreeBSD.ORG Sun Jan 13 18:55:12 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6F4B5EAC; Sun, 13 Jan 2013 18:55:12 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) by mx1.freebsd.org (Postfix) with ESMTP id 8CC863FB; Sun, 13 Jan 2013 18:55:11 +0000 (UTC) Received: by mail-wi0-f171.google.com with SMTP id hn14so830794wib.10 for ; Sun, 13 Jan 2013 10:55:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=f8xvoNkQ5kqQ9akf+3/9C+QOsx4vvXFCJCR801MT2DU=; b=M1sXrUecpxR1qTMXDDtuXPwQy2eMe03yUbjmY66H69XNJttjknFgg8Fk+lTbZDSAyz 48kurb6jtZg4Z3JT3+g8bskvSD/Pg9vxwCmWPEyYoFxdi8Hrw6HIorv7BLKuvp2uJHCs vvpiQEeZz7MboaED1c7E+k+EciRkqPB9fs0mYx/BlclHpE2K6JEuWPo6Z4cICmR3zjrX 4ZwcbtORT1A4a0/zWJ0Ewi5HXbr9UnY9NTLKOiVKtTa9gP2XwFnASqXkh385+c5xzj/w NDlSX5az/HEzKtSW8o4yd+i3Ywh1+wws11quXPGS7aD9okkhgGcdfRyFCgt2MqbehC82 /XrA== MIME-Version: 1.0 Received: by 10.194.179.34 with SMTP id dd2mr131372291wjc.1.1358103310344; Sun, 13 Jan 2013 10:55:10 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Sun, 13 Jan 2013 10:55:10 -0800 (PST) In-Reply-To: <20130113180940.GM26039@alchemy.franken.de> References: <50CCAB99.4040308@FreeBSD.org> <50CE5B54.3050905@FreeBSD.org> <50D03173.9080904@FreeBSD.org> <20121225232126.GA47692@alchemy.franken.de> <50DB4EFE.2020600@FreeBSD.org> <20130106152313.GD26039@alchemy.franken.de> <50EBF921.2000304@FreeBSD.org> <20130113180940.GM26039@alchemy.franken.de> Date: Sun, 13 Jan 2013 10:55:10 -0800 X-Google-Sender-Auth: y_O2qpKyw-1LJ7nR9CGn2iV6RF4 Message-ID: Subject: Re: [RFC/RFT] calloutng From: Adrian Chadd To: Marius Strobl Content-Type: text/plain; charset=ISO-8859-1 Cc: Davide Italiano , Alexander Motin , FreeBSD Current , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 18:55:12 -0000 Ok, So everyone - what _could_ be brought into -HEAD right now, without any actual change in code behaviour? eg, what kind of refactoring could be done to reduce the amount of diffs between the branch and -HEAD? Adrian From owner-freebsd-arch@FreeBSD.ORG Sun Jan 13 19:30:41 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3AF47819 for ; Sun, 13 Jan 2013 19:30:41 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f176.google.com (mail-ie0-f176.google.com [209.85.223.176]) by mx1.freebsd.org (Postfix) with ESMTP id 01AF2789 for ; Sun, 13 Jan 2013 19:30:40 +0000 (UTC) Received: by mail-ie0-f176.google.com with SMTP id 13so4228754iea.21 for ; Sun, 13 Jan 2013 11:30:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=3MIDV+mFMyf/Rvl8Jr8Xb8AYW5Mo8QnwrRl0LXuLcdE=; b=BmHqG92gce1DIItlNvT84j+X8ITrGnp+NnSRe7/7xof395GVxHqR/YYWZ4Pp8y2YK5 zOCX6sxqOtxxKJQdfYDrxhTawzfzJeexTw3Aa7zEIm5E2SXqaT+mpSJkqvR1yuvCn6ZQ qmI+mBJgLgG5WafKWVscwuvdiZjf9f7nWZknTVVJy7vP46xiMf03/NVCK1eOoQ/H8mxG IISw0muBBMFRhU/qoUGZUI0Rf9Zs5fGtLoMO3nfJj1hNPOqrYF3ySNr6d7PcH6Yrh3+I szZrBpPf5Usfz8gMkXJ1pH3RbxSvLNIfiXmKsHMnW/yu6S5wr9Png5uJ5GiY9Z3qRHvF 0BYQ== X-Received: by 10.42.101.144 with SMTP id e16mr62575558ico.5.1358105433962; Sun, 13 Jan 2013 11:30:33 -0800 (PST) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id iw5sm4693638igc.5.2013.01.13.11.30.31 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 13 Jan 2013 11:30:32 -0800 (PST) Sender: Warner Losh Subject: Re: how long to keep support for gcc on x86? Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Sun, 13 Jan 2013 12:30:30 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130112233147.GK1410@funkthat.com> <20130113014242.GA61609@troutmask.apl.washington.edu> To: Adrian Chadd X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQmVs+ynhQBYMO+k3AX+iwrYvHqBaTzHgQixQDjHHK9hToeLuIOQSljv2Iar8RCVRUGg36Q3 Cc: Steve Kargl , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 19:30:41 -0000 On Jan 12, 2013, at 8:30 PM, Adrian Chadd wrote: > IMHO gcc shuld be available until all of the platforms that we > currently ship FreeBSD on gets clang support. >=20 > This includes MIPS (which is there, but I don't think the default MIPS > build uses clang at the moment) and ia64, which Marcel has been > dutifully working on. >=20 > Please also note that people can and will compile FreeBSD on a > non-default-system compiler ; so deprecating gcc (either support or > framework) should be considered carefully. When this was talked about at the clang summit, the overwhelming opinion = expressed was "better with clang". If you can make things better with = clang, great. However, gcc still must work. So no. You can't break gcc build of the kernel. You can make it better = with clang, but you must still support gcc, especially for something = like this. Warner >=20 > Adrian >=20 >=20 > On 12 January 2013 17:42, Steve Kargl = wrote: >> On Sat, Jan 12, 2013 at 03:31:47PM -0800, John-Mark Gurney wrote: >>> So, now that -current x86 is defaulting to clang, how much longer do = we >>> need to support gcc on platforms that default to clang? >>=20 >> IMHO, gcc should be available until after 10.0 is branched. >>=20 >>> I'm asking because clang support AES-NI, but gcc does not... >>=20 >> The last and only time I had for testing clang's handling >> of floating point revealed that clang had a few bugs and >> performance issues. >>=20 >> -- >> Steve >> _______________________________________________ >> freebsd-arch@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arch >> To unsubscribe, send any mail to = "freebsd-arch-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to = "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Sun Jan 13 19:33:13 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 867FE972 for ; Sun, 13 Jan 2013 19:33:13 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) by mx1.freebsd.org (Postfix) with ESMTP id 57BA17AE for ; Sun, 13 Jan 2013 19:33:13 +0000 (UTC) Received: by mail-ie0-f180.google.com with SMTP id c10so4306813ieb.11 for ; Sun, 13 Jan 2013 11:33:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=diRGXwPkVjGVTdMS1l+l8Qg4+PYb0FKHdeo2V+PwSrQ=; b=Vkg0gJinWqD7vYglc/xKjHYgW5SoxV8Foc0pMk3pgYDl/9NlJKl5MXmsdlHLFRNj/7 so9paOnv5lAFYSH1tk/UTjrRdnvT06HSOvEtZVHwfvo7lb0+4xAJ5luXnuzyyZwJgqL5 wPR4TRyGsGcOJan23pUdUm+cOFpZN00R3fYXdVgWg+/RpqiHV3CtIl8g0sNSp9VCzy1E b4DtVVIdK25Y6Mlel6jrQy6QSWn6aapNgfV+URSvkDORLf3hbfvEXj/E0ObhCWnglq9S p+czATKxcsKmP9CZR6IrZmondBOlpkP+N+l/4blFX6jhwiPUuhd+GEcU29QMpaT/L2wc MBDw== X-Received: by 10.42.94.8 with SMTP id z8mr62130733icm.36.1358105592576; Sun, 13 Jan 2013 11:33:12 -0800 (PST) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id bg10sm4696420igc.6.2013.01.13.11.33.10 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 13 Jan 2013 11:33:11 -0800 (PST) Sender: Warner Losh Subject: Re: how long to keep support for gcc on x86? Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20130113053725.GL1410@funkthat.com> Date: Sun, 13 Jan 2013 12:33:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130112233147.GK1410@funkthat.com> <20130113014242.GA61609@troutmask.apl.washington.edu> <20130113053725.GL1410@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQnyXt8mg4Kg69s9A+pasMlKmERnEenJ+jtSsLlzbza+eE0UQdTityfgdliGXt5BIhw03Dpd Cc: Adrian Chadd , Steve Kargl , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 19:33:13 -0000 On Jan 12, 2013, at 10:37 PM, John-Mark Gurney wrote: > Adrian Chadd wrote this message on Sat, Jan 12, 2013 at 19:30 -0800: >> IMHO gcc shuld be available until all of the platforms that we >> currently ship FreeBSD on gets clang support. >=20 > Though, we have a very ancient version of gcc, a modern version would > support the AES-NI intrinsicts that I am thinking of using... It's > more of a question of how long do we need to keep support for gcc > 4.2.1, not another modern gcc/other compiler... You have to support what's in the tree. In the past when people have wanted to use newer instructions, which is = more a binutils thing anyway, they have added support to them in our = in-tree binutils. >> This includes MIPS (which is there, but I don't think the default = MIPS >> build uses clang at the moment) and ia64, which Marcel has been >> dutifully working on. >>=20 >> Please also note that people can and will compile FreeBSD on a >> non-default-system compiler ; so deprecating gcc (either support or >> framework) should be considered carefully. >=20 > Considering that the icc stuff was recently removed, unless the = compiler > has good gcc/clang emulation, I can't see how far another compiler = would > get compiling our code... clang support isn't even complete yet. There are still numerous = unresolved warnings on i386 and amd64 that gcc doesn't complain about. = It is far too premature for desupporting gcc compiles of the kernel. Warner >> On 12 January 2013 17:42, Steve Kargl = wrote: >>> On Sat, Jan 12, 2013 at 03:31:47PM -0800, John-Mark Gurney wrote: >>>> So, now that -current x86 is defaulting to clang, how much longer = do we >>>> need to support gcc on platforms that default to clang? >>>=20 >>> IMHO, gcc should be available until after 10.0 is branched. >>>=20 >>>> I'm asking because clang support AES-NI, but gcc does not... >>>=20 >>> The last and only time I had for testing clang's handling >>> of floating point revealed that clang had a few bugs and >>> performance issues. >=20 > --=20 > John-Mark Gurney Voice: +1 415 225 5579 >=20 > "All that I will do, has been done, All that I have, has not." > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to = "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Sun Jan 13 19:36:19 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0526FA78; Sun, 13 Jan 2013 19:36:19 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1F7347D1; Sun, 13 Jan 2013 19:36:17 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id je9so1649854bkc.13 for ; Sun, 13 Jan 2013 11:36:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=xnpo7wm3oLZBzu3p4xEheCFDqChL1rJ2MXnnQ28rbWI=; b=fHIB2TsZnamwzmqWX07BS1phKbBERZPf0+5EAoV2pkD4srNZVXf1LJkzvYZz1KP1Io j5WE1Nh+V28n+kEn0Fc5z4wq8Dg0EzJeqvhXwhkeqtbK4rO+ReEgllxyc2XRkBv4WQ+i exz4GSXEw6lqB3j5WswF19TH6T0IhBNwT4owMcLwGna2ezu42BcxNM4wGmoXcdZkMokX MZVVajiJoT42mf2Vuo2TfPphSTNXiZqtLDNWeJqT5k8TrFNh7zhMm/TC7av5vZZ/YTC1 2aMWfLG4IP+cOAEiY0ykthDgN94r6yu3H8qNKCU7mGHSQ879sa+fgHN0zVR7xEh1f/bq ZJxw== X-Received: by 10.204.131.74 with SMTP id w10mr37768753bks.4.1358105776764; Sun, 13 Jan 2013 11:36:16 -0800 (PST) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id y11sm8181416bkw.8.2013.01.13.11.36.13 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 13 Jan 2013 11:36:15 -0800 (PST) Sender: Alexander Motin Message-ID: <50F30CAB.3000001@FreeBSD.org> Date: Sun, 13 Jan 2013 21:36:11 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Marius Strobl Subject: Re: [RFC/RFT] calloutng References: <50CCAB99.4040308@FreeBSD.org> <50CE5B54.3050905@FreeBSD.org> <50D03173.9080904@FreeBSD.org> <20121225232126.GA47692@alchemy.franken.de> <50DB4EFE.2020600@FreeBSD.org> <20130106152313.GD26039@alchemy.franken.de> <50EBF921.2000304@FreeBSD.org> <20130113180940.GM26039@alchemy.franken.de> In-Reply-To: <20130113180940.GM26039@alchemy.franken.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Davide Italiano , FreeBSD Current , freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 19:36:19 -0000 On 13.01.2013 20:09, Marius Strobl wrote: > On Tue, Jan 08, 2013 at 12:46:57PM +0200, Alexander Motin wrote: >> On 06.01.2013 17:23, Marius Strobl wrote: >>> I'm not really sure what to do about that. Earlier you already said >>> that sched_bind(9) also isn't an option in case if td_critnest > 1. >>> To be honest, I don't really unerstand why using a spin lock in the >>> timecounter path makes sparc64 the only problematic architecture >>> for your changes. The x86 i8254_get_timecount() also uses a spin lock >>> so it should be in the same boat. >> >> The problem is not in using spinlock, but in waiting for other CPU while >> spinlock is held. Other CPU may also hold spinlock and wait for >> something, causing deadlock. i8254 code uses spinlock just to atomically >> access hardware registers, so it causes no problems. > > Okay, but wouldn't that be a general problem then? Pretty much > anything triggering an IPI holds smp_ipi_mtx while doing so and > the lower level IPI stuff waits for other CPU(s), including on > x86. The problem is general. But now it works because single smp_ipi_mtx is used in all cases where IPI result is waited. As soon as spinning happens with interrupts still enabled, there is no deadlocks. But problem reappears if any different lock is used, or locks are nested. In existing code in HEAD and 9 timecounters are never called with spin mutex held. I intentionally tried to avoid that in existing eventtimers code. Callout code same time can be called in any environment with any locks held. And new callout code may need to know precise current time in any of those conditions. Attempt to use an IPI and wait there can be fatal. >>> The affected machines are equipped with a x86-style south bridge >>> which exposes a powermanagment unit (intended to be used as a SMBus >>> bridge only in these machines) on the PCI bus. Actually, this device >>> also includes an ACPI power management timer. However, I've just >>> spent a day trying to get that one working without success - it >>> just doesn't increment. Probably its clock input isn't connected as >>> it's not intended to be used in these machines. >>> That south bridge also includes 8254 compatible timers on the ISA/ >>> LPC side, but are hidden from the OFW device tree. I can hack these >>> devices into existence and give it a try, but even if that works this >>> likely would use the same code as the x86 i8254_get_timecount() so I >>> don't see what would be gained with that. >>> >>> The last thing in order to avoid using the tick counter as timecounter >>> in the MP case I can think of is that the Broadcom MACs in the affected >>> machines also provide a counter driven by a 1 MHz clock. If that's good >>> enough for a timecounter I can hook these up (in case these work ...) >>> and hack bge(4) to not detach in that case (given that we can't detach >>> timecounters ...). >> >> i8254 on x86 is also just a bit above 1MHz. >> >>>> Here is small tool we are using for test correctness and performance of >>>> different user-level APIs: http://people.freebsd.org/~mav/testsleep.c >>>> >>> >>> I've run Ian's set of tests on a v215 with and without your >>> calloutng_12_26.patch and on a v210 (these uses the IPI approach) >>> with the latter also applied. >>> I'm not really sure what to make out of the numbers. >>> >>> v215 w/o v215 w/ v210 w/ >>> ---------- ---------------- ---------------- ---------------- >>> select 1 1999.61 1 23.87 1 29.97 >>> poll 1 1999.70 1 1069.61 1 1075.24 >>> usleep 1 1999.86 1 23.43 1 28.99 >>> nanosleep 1 999.92 1 23.28 1 28.66 >>> kqueue 1 1000.12 1 1071.13 1 1076.35 >>> kqueueto 1 999.56 1 26.33 1 31.34 >>> syscall 1 1.89 1 1.92 1 2.88 > > FYI, these are the results of the v215 (btw., these (ab)use a bus > cycle counter of the host-PCI-bridge as timecounter) with your > calloutng_12_17.patch and kern.timecounter.alloweddeviation=0: > select 1 23.82 > poll 1 1008.23 > usleep 1 23.31 > nanosleep 1 23.17 > kqueue 1 1010.35 > kqueueto 1 26.26 > syscall 1 1.91 > select 300 307.72 > poll 300 1008.23 > usleep 300 307.64 > nanosleep 300 23.21 > kqueue 300 1010.49 > kqueueto 300 26.27 > syscall 300 1.92 > select 3000 3009.95 > poll 3000 3013.33 > usleep 3000 3013.56 > nanosleep 3000 23.17 > kqueue 3000 3011.09 > kqueueto 3000 26.24 > syscall 3000 1.91 > select 30000 30013.51 > poll 30000 30010.63 > usleep 30000 30010.64 > nanosleep 30000 36.91 > kqueue 30000 30012.38 > kqueueto 30000 39.90 > syscall 30000 1.90 > select 300000 300017.52 > poll 300000 300013.00 > usleep 300000 300012.64 > nanosleep 300000 307.59 > kqueue 300000 300017.07 > kqueueto 300000 310.24 > syscall 300000 1.93 It seems that extra delay is only about 10-17us. >> Numbers are not bad, respecting the fact that to protect from lost >> interrupts eventtimer code on sparc64 now sets minimal programming >> interval to 15us. It was made to reduce race window between the timer >> read-modify-write and some long NMIs. > > Uhm, there are no NMIs on sparc64. Does it make sense to bypass this > adjustment on sparc64? If it is not possible or not good to to stop timer during programming, there will always be some race window between code execution and timer ticking. So some minimal safety range should be reserved. Though it probably can be significantly reduced. In case of x86/HPET there is additional factor of NMI, that extends race to unpredictable level and so makes additional post-read almost mandatory. >> May be with rereading counter >> after programming comparator (same as done for HPET, reading which is >> probably much more expensive) this value could be reduced. > > I see. There are some bigger fish to fry at the moment though :) :) -- Alexander Motin From owner-freebsd-arch@FreeBSD.ORG Sun Jan 13 20:24:41 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D70ED9E4; Sun, 13 Jan 2013 20:24:41 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) by mx1.freebsd.org (Postfix) with ESMTP id 93BA99C9; Sun, 13 Jan 2013 20:24:41 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r0DKOZpH099223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 13 Jan 2013 12:24:35 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r0DKOZTl099222; Sun, 13 Jan 2013 12:24:35 -0800 (PST) (envelope-from jmg) Date: Sun, 13 Jan 2013 12:24:35 -0800 From: John-Mark Gurney To: Nathan Whitehorn Subject: Re: LLVM Image Activator Message-ID: <20130113202435.GN1410@funkthat.com> Mail-Followup-To: Nathan Whitehorn , Konstantin Belousov , Ed Schouten , freebsd-toolchain@freebsd.org, freebsd-arch@freebsd.org References: <50E9BC2D.7000302@freebsd.org> <201301070936.39052.jhb@freebsd.org> <20130107172433.GX82219@kib.kiev.ua> <20130113132057.GQ2561@kib.kiev.ua> <50F2DF11.50202@freebsd.org> <20130113171304.GZ2561@kib.kiev.ua> <50F2F97B.5030306@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50F2F97B.5030306@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sun, 13 Jan 2013 12:24:35 -0800 (PST) Cc: Konstantin Belousov , Ed Schouten , freebsd-toolchain@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 20:24:41 -0000 Nathan Whitehorn wrote this message on Sun, Jan 13, 2013 at 10:14 -0800: > On 01/13/13 09:13, Konstantin Belousov wrote: > > On Sun, Jan 13, 2013 at 08:21:37AM -0800, Nathan Whitehorn wrote: > >> On 01/13/13 05:20, Konstantin Belousov wrote: > >>> On Sun, Jan 13, 2013 at 12:41:09PM +0100, Ed Schouten wrote: > >>>> Hi Kostik, > >>>> > >>>> 2013/1/7 Konstantin Belousov : > >>>>> I still do remember the buzz about the binary format 0xCAFEBABE, which > >>>>> AFAIR gained image activator support on several OSes, to be garbage > >>>>> collected. > >>>> > >>>> Maybe it would then be a good idea then to add some kind of general > >>>> purpose remapping imgact? Example: > >>>> > >>>> /etc/imgacttab: > >>>> > >>>> cafebabe /usr/local/bin/java > >>>> cffaedfe /usr/local/bin/osx_emulator > >>>> 4243c0de /usr/bin/lli > >>>> > >>>> That way we still give people the freedom to play around with mapping > >>>> their own executable formats, but don't need to maintain a bunch of > >>>> imgacts. > >>> > >>> A generic module that could be somewhat customized at runtime to map > >>> offset+signature into the shebang path could be a possibility indeed. > >>> I strongly prefer to have it as module and not enabled by default. > >>> > >>> Asking Nathan for writing the thing is too much, IMHO, esp. in > >>> the response to the 50-lines hack. > >>> > >> > >> I think this is a good idea, since it both prevents a profusion of > >> similar activators and works nicely in jails and similar environments. I > >> probably won't write it quickly, but it should not take more than about > >> 50 lines, so I can't imagine it will be that bad. There are some > >> complications with this kind of design from the things in the XXX > >> comment in imgact_llvm.c about handling argv[0] that I need to think > >> some more about. > > Great. I do not believe in the 50 lines, but I am happy that you want > > to work this out. > > > >> > >> Why are you opposed to having it there by default? I think it's actually > >> quite important that it be there by default. Having it not "standard" > >> would be fine, but it should at least be in GENERIC. There are minimal > >> security risks since it just munges begin_argv and doesn't even load the > >> executable and it's little enough code that there should not be any > >> kernel bloat to speak of. If things like this aren't enabled by default, > >> no one can depend on them being there, no one will use it, and the point > >> is entirely lost. > > All image activators demonstrated a constant stream of security holes. > > Even our ELF activator, and I was guilty there too. > > > > I definitely do not fight over the inclusion of the proposed activator > > into GENERIC, but do insist on the config option + module. > > > > OK, that sounds like a plan then. I'll try to code up something > configurable in the next couple weeks, unless someone else beats me to it. I'll point out that file already has the magic (pun intended) that we are looking for, though I do realize that the code might be a bit much to import.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@FreeBSD.ORG Sun Jan 13 20:29:53 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D7742C32; Sun, 13 Jan 2013 20:29:53 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) by mx1.freebsd.org (Postfix) with ESMTP id AE2179F6; Sun, 13 Jan 2013 20:29:53 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r0DKTrNS099306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 13 Jan 2013 12:29:53 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r0DKTrEl099305; Sun, 13 Jan 2013 12:29:53 -0800 (PST) (envelope-from jmg) Date: Sun, 13 Jan 2013 12:29:52 -0800 From: John-Mark Gurney To: Adrian Chadd Subject: Re: how long to keep support for gcc on x86? Message-ID: <20130113202952.GO1410@funkthat.com> Mail-Followup-To: Adrian Chadd , Steve Kargl , freebsd-arch@freebsd.org References: <20130112233147.GK1410@funkthat.com> <20130113014242.GA61609@troutmask.apl.washington.edu> <20130113053725.GL1410@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sun, 13 Jan 2013 12:29:53 -0800 (PST) Cc: Steve Kargl , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 20:29:53 -0000 Adrian Chadd wrote this message on Sat, Jan 12, 2013 at 23:44 -0800: > > People are still ironing out kinks/differences with clang. Anyone > saying otherwise is likely pushing an agenda. :-) > > Thus I think adding clang-only code to the system right now is very, > very premature. There still seem to be reasons to run systems on GCC > instead of clang. > > If you have a need for new instruction support, perhaps look at adding > it to our base GCC for the time being? I did look at it briefly, but I don't know gcc's internals, and it would take me 5+ hours to do it, while someone who does know gcc would take abount a half an hour (just a guess)... I don't have the free time I used to, otherwise I would of done it by now.. > Remember, you're not the only consumer of the system. :-) Hence why I asked.. :) -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@FreeBSD.ORG Sun Jan 13 20:33:21 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C70BBEE3; Sun, 13 Jan 2013 20:33:21 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) by mx1.freebsd.org (Postfix) with ESMTP id 88BD4A2E; Sun, 13 Jan 2013 20:33:21 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r0DKXL5f099390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 13 Jan 2013 12:33:21 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r0DKXK3K099389; Sun, 13 Jan 2013 12:33:20 -0800 (PST) (envelope-from jmg) Date: Sun, 13 Jan 2013 12:33:20 -0800 From: John-Mark Gurney To: Konstantin Belousov Subject: Re: how long to keep support for gcc on x86? Message-ID: <20130113203320.GP1410@funkthat.com> Mail-Followup-To: Konstantin Belousov , Peter Wemm , Adrian Chadd , freebsd-arch@freebsd.org References: <20130112233147.GK1410@funkthat.com> <20130113014242.GA61609@troutmask.apl.washington.edu> <20130113053725.GL1410@funkthat.com> <20130113132402.GR2561@kib.kiev.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130113132402.GR2561@kib.kiev.ua> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sun, 13 Jan 2013 12:33:21 -0800 (PST) Cc: Adrian Chadd , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 20:33:21 -0000 Konstantin Belousov wrote this message on Sun, Jan 13, 2013 at 15:24 +0200: > On Sun, Jan 13, 2013 at 12:09:09AM -0800, Peter Wemm wrote: > > On Sat, Jan 12, 2013 at 11:44 PM, Adrian Chadd wrote: > > > > > Thus I think adding clang-only code to the system right now is very, > > > very premature. There still seem to be reasons to run systems on GCC > > > instead of clang. > > > > I don't have a problem with it so long as the system isn't *broken* if > > you're not using clang. ie: if the status-quo is maintained for gcc > > systems and g-faster bits are enabled with clang. It's fine to > > provide incentives to try clang, but it is not ok to regress the gcc > > case. > Absolutely agree. > > Please note that in the AES-NI case, gcc 'support' is only partially > gcc issue, if gcc at all. Our 2.17 gas does not know about AES-NI > mnemonics and cannot assemble them. gcc support would be better than gas support belive it or not.. > AFAIR the patch uses C built-in for AES-NI and SSE3 or 4, which I think > could be implemented manually in the amount needed for the patch, for > old gcc. It was actually using assembly functions since gcc doesn't have the necessary intrinsics... If it did, I could make things go even faster for both i386 and amd64... As it stands, the i386 implementation will be a bit slower since I'll have to pass in more of the blocks via stack instead of registers... amd64 allows 8 128bit args passed in via reg, while i386 only allows three... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@FreeBSD.ORG Sun Jan 13 20:45:09 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0D79664A; Sun, 13 Jan 2013 20:45:09 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) by mx1.freebsd.org (Postfix) with ESMTP id B80FEAB4; Sun, 13 Jan 2013 20:45:07 +0000 (UTC) Received: by mail-we0-f177.google.com with SMTP id x48so1739075wey.22 for ; Sun, 13 Jan 2013 12:45:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Ux6Kc7xf62oVjwpPbMRBhx86a59mcVFLdG7i3kI364w=; b=PBAeqPabPhgJss31wKGaCnSfptuN/WJ24fQsuQkEkam6wUauQBOtpwdZNdkn5MrYcJ cehaxYzHHJGiIxrwrtoKyblsMTxDCi9MQUQNHzxoBSuMn7bhbFokCuiEIvOM45wmNPr0 CBBNE0AxISCwZla9Gio6W0nKO4XhrSsq0aHo0mQCLAHjAet4MKomFucMuGpRNMXTQRJS /Q49xUu3rQ36D3+eL0meZ5ql7D7mk9Me1nw7sRkTE691F68Rx5ObIjml4CCWH9IHyIPf 89JNbeic3ALJe2bbxuZqrKdSbExAZ0YVeo/mauiqn3CgWBd9C48lTs8QMPDYhguSiow1 fOdg== MIME-Version: 1.0 X-Received: by 10.180.93.133 with SMTP id cu5mr8908659wib.32.1358109906576; Sun, 13 Jan 2013 12:45:06 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Sun, 13 Jan 2013 12:45:06 -0800 (PST) In-Reply-To: <50F2F79C.7040109@mu.org> References: <201211272119.qARLJxXV061083@svn.freebsd.org> <50C1BC90.90106@freebsd.org> <50C25A27.4060007@bluezbox.com> <50C26331.6030504@freebsd.org> <50C26AE9.4020600@bluezbox.com> <50C3A3D3.9000804@freebsd.org> <50C3AF72.4010902@rice.edu> <330405A1-312A-45A5-BB86-4969478D8BBD@bluezbox.com> <50D03E83.8060908@rice.edu> <50DD081E.8000409@bluezbox.com> <50EB1841.5030006@bluezbox.com> <50EB22D2.6090103@rice.edu> <50EB415F.8020405@freebsd.org> <50F04FE5.7010406@rice.edu> <50F1BD69.4060104@mu.org> <50F2F79C.7040109@mu.org> Date: Sun, 13 Jan 2013 12:45:06 -0800 X-Google-Sender-Auth: NJJ1tZuTaqXvaQ9ziZpjmySGud8 Message-ID: Subject: Re: svn commit: r243631 - in head/sys: kern sys From: Adrian Chadd To: Alfred Perlstein Content-Type: text/plain; charset=ISO-8859-1 Cc: src-committers@freebsd.org, Andre Oppermann , Alan Cox , "Jayachandran C." , svn-src-all@freebsd.org, Oleksandr Tymoshenko , freebsd-arch@freebsd.org, svn-src-head@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 20:45:09 -0000 .. I think the "right" solution is to still review what things rely on maxusers/maxfiles/etc and figure out which make sense to scale off of a global variable, and which don't. Adrian From owner-freebsd-arch@FreeBSD.ORG Sun Jan 13 22:26:41 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9B7AE8E5 for ; Sun, 13 Jan 2013 22:26:41 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-vc0-f173.google.com (mail-vc0-f173.google.com [209.85.220.173]) by mx1.freebsd.org (Postfix) with ESMTP id 4305221B for ; Sun, 13 Jan 2013 22:26:40 +0000 (UTC) Received: by mail-vc0-f173.google.com with SMTP id f13so3005573vcb.18 for ; Sun, 13 Jan 2013 14:26:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=w8phwmwlG8RO3RSNaeyuEnH4He+HjwkTDky+WzFy+Os=; b=UlajoHRIlGxv70ds8M1mm6Z4K4GSz3lbjSS1adJ6R8bzWv6zxq3sc0sxoYniV7Y7Xn 1SDr4CT8bv/pjBFMBTi790K4OTiI8umsAACEsHo8uiZLRw3jsHEopRmgGE5tB3753Wpo xNdFrjIA8kjo7gXhrWJed7pL2XZ4ncy8a7He8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=w8phwmwlG8RO3RSNaeyuEnH4He+HjwkTDky+WzFy+Os=; b=CQndBhuzlDdqGbvhoP4eJp/D5OGeB7ya/vW7fTOCdOo8m8ppzxokAuBKfNzusYAPO8 AP9nOGQ762c9X8c01Dkd/SmygznA48FIimPV852zbt2bRFWIndwR57bHChoiYYI7lRwX 2OA5vNZAhJDCnmrhXE8avExCrKuIfumHiTkxwIH4gpkFbP48vm9vnU2NjRRD24Yj9iJf YshLZLD1phN60bj1+CFaehm4X8OoGWo/su9cMHB7o/pt6tYlq1xl24onviw3Xbe0Nh1r pRQl/dWwtX34S4WUlWKYYEd5OuyjSp3d+v4/pT4i6k702BTPJeDy07T/UszKC2MKLftA unOw== MIME-Version: 1.0 Received: by 10.220.209.74 with SMTP id gf10mr99001908vcb.10.1358116000204; Sun, 13 Jan 2013 14:26:40 -0800 (PST) Received: by 10.220.174.135 with HTTP; Sun, 13 Jan 2013 14:26:40 -0800 (PST) In-Reply-To: <20130113202952.GO1410@funkthat.com> References: <20130112233147.GK1410@funkthat.com> <20130113014242.GA61609@troutmask.apl.washington.edu> <20130113053725.GL1410@funkthat.com> <20130113202952.GO1410@funkthat.com> Date: Sun, 13 Jan 2013 14:26:40 -0800 Message-ID: Subject: Re: how long to keep support for gcc on x86? From: Peter Wemm To: Adrian Chadd , freebsd-arch@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkSQ4GMpjYFoaGzxq+0jx5L6yGZfzb1DhHKmL2Sh8PysUvvFdqPk3eNFvPluQTGInF229ck X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 22:26:41 -0000 On Sun, Jan 13, 2013 at 12:29 PM, John-Mark Gurney wrote: > Adrian Chadd wrote this message on Sat, Jan 12, 2013 at 23:44 -0800: >> >> People are still ironing out kinks/differences with clang. Anyone >> saying otherwise is likely pushing an agenda. :-) >> >> Thus I think adding clang-only code to the system right now is very, >> very premature. There still seem to be reasons to run systems on GCC >> instead of clang. >> >> If you have a need for new instruction support, perhaps look at adding >> it to our base GCC for the time being? > > I did look at it briefly, but I don't know gcc's internals, and it would > take me 5+ hours to do it, while someone who does know gcc would take > abount a half an hour (just a guess)... I don't have the free time I > used to, otherwise I would of done it by now.. It seems to me that since clang is the default compiler for the platforms that have AES-NI that the following could be done: * get the inline AES-NI stuff in and debugged and solid. * .. without breaking the existing gcc-compatible code * once the support is solid, decide what the appropriate thing to do for gcc is. .. so long as the existing code doesn't get broken. Trying to do backwards compatibility port to gcc with a moving target has potential to be a work multiplier. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV bitcoin:188ZjyYLFJiEheQZw4UtU27e2FMLmuRBUE From owner-freebsd-arch@FreeBSD.ORG Sun Jan 13 22:48:01 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 605286B9; Sun, 13 Jan 2013 22:48:01 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) by mx1.freebsd.org (Postfix) with ESMTP id 3C7DF2DF; Sun, 13 Jan 2013 22:48:00 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r0DMm0gH001549 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 13 Jan 2013 14:48:00 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r0DMm0JT001548; Sun, 13 Jan 2013 14:48:00 -0800 (PST) (envelope-from jmg) Date: Sun, 13 Jan 2013 14:48:00 -0800 From: John-Mark Gurney To: Peter Wemm Subject: Re: how long to keep support for gcc on x86? Message-ID: <20130113224800.GS1410@funkthat.com> Mail-Followup-To: Peter Wemm , Adrian Chadd , freebsd-arch@freebsd.org References: <20130112233147.GK1410@funkthat.com> <20130113014242.GA61609@troutmask.apl.washington.edu> <20130113053725.GL1410@funkthat.com> <20130113202952.GO1410@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sun, 13 Jan 2013 14:48:00 -0800 (PST) Cc: Adrian Chadd , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 22:48:01 -0000 Peter Wemm wrote this message on Sun, Jan 13, 2013 at 14:26 -0800: > On Sun, Jan 13, 2013 at 12:29 PM, John-Mark Gurney wrote: > > Adrian Chadd wrote this message on Sat, Jan 12, 2013 at 23:44 -0800: > >> > >> People are still ironing out kinks/differences with clang. Anyone > >> saying otherwise is likely pushing an agenda. :-) > >> > >> Thus I think adding clang-only code to the system right now is very, > >> very premature. There still seem to be reasons to run systems on GCC > >> instead of clang. > >> > >> If you have a need for new instruction support, perhaps look at adding > >> it to our base GCC for the time being? > > > > I did look at it briefly, but I don't know gcc's internals, and it would > > take me 5+ hours to do it, while someone who does know gcc would take > > abount a half an hour (just a guess)... I don't have the free time I > > used to, otherwise I would of done it by now.. > > It seems to me that since clang is the default compiler for the > platforms that have AES-NI that the following could be done: > > * get the inline AES-NI stuff in and debugged and solid. > * .. without breaking the existing gcc-compatible code > * once the support is solid, decide what the appropriate thing to do for gcc is. > > .. so long as the existing code doesn't get broken. > > Trying to do backwards compatibility port to gcc with a moving target > has potential to be a work multiplier. I already have a gcc compatible version of an improved AES-NI for amd64... The real question is, do I improve things further by using intrinsics which means we can share code between amd64 and i386 and get great performance from both, or do I simply make a seperate version for i386 that is gcc compatible, but not as good performance... Though a lot of this last little bit of performance questions isn't too useful since the overhead of the crypto framework and geom introduces a significant overhead already... I'm not too interesting in creating AES-NI v2 module and having two versions that do the same thing just because of a compiler issue... So I'm going to go with the plan of making an i386 and gcc compatible version... it'll still be a 4x+ performance over the existing code... This also means we could back port it to 9-stable if we wanted to... Thanks for the input... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@FreeBSD.ORG Sun Jan 13 22:53:25 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8DA738BA for ; Sun, 13 Jan 2013 22:53:25 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) by mx1.freebsd.org (Postfix) with ESMTP id 0F943308 for ; Sun, 13 Jan 2013 22:53:24 +0000 (UTC) Received: by mail-lb0-f181.google.com with SMTP id ge1so2476776lbb.26 for ; Sun, 13 Jan 2013 14:53:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=ak5AfRx5TzLyyIgqE7VOSmYhYT1iC6RuEGnilbDVDRs=; b=Nha2z3otxaD+sAooejx5A1IcJFXA+hXjgUHuWfa9I0PFrPJXYG0CPkkt5Auk+7D960 9bNzTISgfq+5t8/ThLOhFQYicaStrJXTkchIHNkcMhlrV3XmbOKPaB26byL26bWVKxvn i+MVyssuDvxUTPOEy0WMLhbi++eH0Lg858+2k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=ak5AfRx5TzLyyIgqE7VOSmYhYT1iC6RuEGnilbDVDRs=; b=VX9BM7iluab+VslhyJTctz47iu5VDqy385/NZTXS4OymqYpNnHYZaemv/uBKLFhvLo nkIpeOC7HswGOlRgZvv5rIgE4IICUDTxNfe/jByBiA8+9VBIYYOfFVcF69woCWVG7s+G pJr8l+cw7BG3MDR02BF/oNRrfLh6m9lALNzyId4jLsFaigMFCGrNn7cFku0mz0ifpH1l HkcQ3heH2J3YLjv2794yWFJkIXWMpn2a+9DcXenT5sj52AJ01SxUYhuAN2DuOOqeolip BKhl+83pQy0wOL0d/qI7b/bpKKR2gL2iHc/GJe8vmRhQaqXv7zfvgGa6GZjFBfKkC/CY AoxQ== Received: by 10.112.23.2 with SMTP id i2mr34942345lbf.24.1358117603657; Sun, 13 Jan 2013 14:53:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.151.36 with HTTP; Sun, 13 Jan 2013 14:52:52 -0800 (PST) In-Reply-To: <20130113224800.GS1410@funkthat.com> References: <20130112233147.GK1410@funkthat.com> <20130113014242.GA61609@troutmask.apl.washington.edu> <20130113053725.GL1410@funkthat.com> <20130113202952.GO1410@funkthat.com> <20130113224800.GS1410@funkthat.com> From: Eitan Adler Date: Sun, 13 Jan 2013 17:52:52 -0500 Message-ID: Subject: Re: how long to keep support for gcc on x86? To: Peter Wemm , Adrian Chadd , freebsd-arch@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQkdc059TQ4JcAye4O8KpEqXbg7fSAt7/RknwMWQLN//Fstt4JeBuTC2PlkwneVHTqTFZJeB X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 22:53:25 -0000 On 13 January 2013 17:48, John-Mark Gurney wrote: > I already have a gcc compatible version of an improved AES-NI for > amd64... The real question is, do I improve things further by using > intrinsics which means we can share code between amd64 and i386 and get > great performance from both, or do I simply make a seperate version > for i386 that is gcc compatible, but not as good performance... Maybe throw the "very improved" version into a comment that can be used later, when the compiler is not an issue? -- Eitan Adler From owner-freebsd-arch@FreeBSD.ORG Sun Jan 13 22:54:02 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CA2FD960 for ; Sun, 13 Jan 2013 22:54:02 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from agogare.doit.wisc.edu (agogare.doit.wisc.edu [144.92.197.211]) by mx1.freebsd.org (Postfix) with ESMTP id A2CAE311 for ; Sun, 13 Jan 2013 22:54:02 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from avs-daemon.smtpauth2.wiscmail.wisc.edu by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0MGL0060069W4C00@smtpauth2.wiscmail.wisc.edu> for freebsd-arch@freebsd.org; Sun, 13 Jan 2013 16:53:56 -0600 (CST) Received: from wanderer.tachypleus.net (c-24-63-204-107.hsd1.ct.comcast.net [24.63.204.107]) by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0MGL004YO69UFK00@smtpauth2.wiscmail.wisc.edu> for freebsd-arch@freebsd.org; Sun, 13 Jan 2013 16:53:55 -0600 (CST) Date: Sun, 13 Jan 2013 14:53:54 -0800 From: Nathan Whitehorn Subject: Re: how long to keep support for gcc on x86? In-reply-to: <20130113224800.GS1410@funkthat.com> Sender: whitehorn@wisc.edu To: freebsd-arch@freebsd.org Message-id: <50F33B02.6040303@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=24.63.204.107 X-Spam-PmxInfo: Server=avs-13, Version=5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.1.13.224528, SenderIP=24.63.204.107 References: <20130112233147.GK1410@funkthat.com> <20130113014242.GA61609@troutmask.apl.washington.edu> <20130113053725.GL1410@funkthat.com> <20130113202952.GO1410@funkthat.com> <20130113224800.GS1410@funkthat.com> User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130112 Thunderbird/17.0.2 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 22:54:02 -0000 On 01/13/13 14:48, John-Mark Gurney wrote: > Peter Wemm wrote this message on Sun, Jan 13, 2013 at 14:26 -0800: >> On Sun, Jan 13, 2013 at 12:29 PM, John-Mark Gurney wrote: >>> Adrian Chadd wrote this message on Sat, Jan 12, 2013 at 23:44 -0800: >>>> >>>> People are still ironing out kinks/differences with clang. Anyone >>>> saying otherwise is likely pushing an agenda. :-) >>>> >>>> Thus I think adding clang-only code to the system right now is very, >>>> very premature. There still seem to be reasons to run systems on GCC >>>> instead of clang. >>>> >>>> If you have a need for new instruction support, perhaps look at adding >>>> it to our base GCC for the time being? >>> >>> I did look at it briefly, but I don't know gcc's internals, and it would >>> take me 5+ hours to do it, while someone who does know gcc would take >>> abount a half an hour (just a guess)... I don't have the free time I >>> used to, otherwise I would of done it by now.. >> >> It seems to me that since clang is the default compiler for the >> platforms that have AES-NI that the following could be done: >> >> * get the inline AES-NI stuff in and debugged and solid. >> * .. without breaking the existing gcc-compatible code >> * once the support is solid, decide what the appropriate thing to do for gcc is. >> >> .. so long as the existing code doesn't get broken. >> >> Trying to do backwards compatibility port to gcc with a moving target >> has potential to be a work multiplier. > > I already have a gcc compatible version of an improved AES-NI for > amd64... The real question is, do I improve things further by using > intrinsics which means we can share code between amd64 and i386 and get > great performance from both, or do I simply make a seperate version > for i386 that is gcc compatible, but not as good performance... > > Though a lot of this last little bit of performance questions isn't too > useful since the overhead of the crypto framework and geom introduces > a significant overhead already... > > I'm not too interesting in creating AES-NI v2 module and having two > versions that do the same thing just because of a compiler issue... > > So I'm going to go with the plan of making an i386 and gcc compatible > version... it'll still be a 4x+ performance over the existing code... > This also means we could back port it to 9-stable if we wanted to... > > Thanks for the input... > This also raises the interesting question of whether we want to bother supporting things like AES-NI on i386 at all. It's a legacy/embedded architecture at this point, in my opinion, and the people who run it probably don't care about fancy new features like this. A related question is whether we want to have any clang-only features in the kernel... -Nathan From owner-freebsd-arch@FreeBSD.ORG Sun Jan 13 23:00:12 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F2A39B30 for ; Sun, 13 Jan 2013 23:00:12 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-vc0-f173.google.com (mail-vc0-f173.google.com [209.85.220.173]) by mx1.freebsd.org (Postfix) with ESMTP id A5E1A357 for ; Sun, 13 Jan 2013 23:00:12 +0000 (UTC) Received: by mail-vc0-f173.google.com with SMTP id f13so3004281vcb.4 for ; Sun, 13 Jan 2013 15:00:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=M8Sk7jAlnzfxu9TTFMm3Mc7PxN3oqdpFoP0WVndoBR8=; b=kDlP+5bHhJiwatfQf8YyZFDCWgsVH5ZGk89N39FUsWvpWvEulKeE5/GZXoLup0I0/y hlV626F50PnNC9FVbolXtC5l6yTDWf5ztngQ71gDHVjnfCA51lLWlisWU++04OAz/b7C PjCVHm2XHyCOpAlIIvq2/r0C66tKzoYQ5WX5o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=M8Sk7jAlnzfxu9TTFMm3Mc7PxN3oqdpFoP0WVndoBR8=; b=lQQ1FxBe5DJ3n3vaPyZ5ke9LPiC3g22zR7RUloDph4TjuTjVx6prGbamjgbWQH3Xee bmbEkwSZUp2+z/Xa5q/kTUxSMjj8ahMsG4G6fNpG1RIddde2YG54uMXkpFW/ZF69Ny2m 1EhIrqsaBNofmXQkEh3WB1HUsrFvJhumUBGxltD9KiJWAR3u6VMZkIJ5iV9VzTFniz/C uZG8ByZWqxBXLkF2Epa0EanEMPQI7lG1Zm/sU8HKOZMhlRvedms4FK0zD5JGRY8/l/e1 KHISSIB+6NKNlcyN+N+WMbbxzAXeh+YwlWCKP98OEfUoXAWessGyNFdsFyYIqZvlqawD eu5w== MIME-Version: 1.0 Received: by 10.52.36.19 with SMTP id m19mr85816210vdj.33.1358118011729; Sun, 13 Jan 2013 15:00:11 -0800 (PST) Received: by 10.220.174.135 with HTTP; Sun, 13 Jan 2013 15:00:11 -0800 (PST) In-Reply-To: <50F33B02.6040303@freebsd.org> References: <20130112233147.GK1410@funkthat.com> <20130113014242.GA61609@troutmask.apl.washington.edu> <20130113053725.GL1410@funkthat.com> <20130113202952.GO1410@funkthat.com> <20130113224800.GS1410@funkthat.com> <50F33B02.6040303@freebsd.org> Date: Sun, 13 Jan 2013 15:00:11 -0800 Message-ID: Subject: Re: how long to keep support for gcc on x86? From: Peter Wemm To: Nathan Whitehorn Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQntudNqrQuy6aSfoeKnm/pKP0Yc3cCqPWjhEn6azrLSCg2+iLF/5szpJ3aVzWQ5xkputXOW Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 23:00:13 -0000 On Sun, Jan 13, 2013 at 2:53 PM, Nathan Whitehorn wrote: > On 01/13/13 14:48, John-Mark Gurney wrote: >> Peter Wemm wrote this message on Sun, Jan 13, 2013 at 14:26 -0800: >>> On Sun, Jan 13, 2013 at 12:29 PM, John-Mark Gurney wrote: >>>> Adrian Chadd wrote this message on Sat, Jan 12, 2013 at 23:44 -0800: >>>>> >>>>> People are still ironing out kinks/differences with clang. Anyone >>>>> saying otherwise is likely pushing an agenda. :-) >>>>> >>>>> Thus I think adding clang-only code to the system right now is very, >>>>> very premature. There still seem to be reasons to run systems on GCC >>>>> instead of clang. >>>>> >>>>> If you have a need for new instruction support, perhaps look at adding >>>>> it to our base GCC for the time being? >>>> >>>> I did look at it briefly, but I don't know gcc's internals, and it would >>>> take me 5+ hours to do it, while someone who does know gcc would take >>>> abount a half an hour (just a guess)... I don't have the free time I >>>> used to, otherwise I would of done it by now.. >>> >>> It seems to me that since clang is the default compiler for the >>> platforms that have AES-NI that the following could be done: >>> >>> * get the inline AES-NI stuff in and debugged and solid. >>> * .. without breaking the existing gcc-compatible code >>> * once the support is solid, decide what the appropriate thing to do for gcc is. >>> >>> .. so long as the existing code doesn't get broken. >>> >>> Trying to do backwards compatibility port to gcc with a moving target >>> has potential to be a work multiplier. >> >> I already have a gcc compatible version of an improved AES-NI for >> amd64... The real question is, do I improve things further by using >> intrinsics which means we can share code between amd64 and i386 and get >> great performance from both, or do I simply make a seperate version >> for i386 that is gcc compatible, but not as good performance... >> >> Though a lot of this last little bit of performance questions isn't too >> useful since the overhead of the crypto framework and geom introduces >> a significant overhead already... >> >> I'm not too interesting in creating AES-NI v2 module and having two >> versions that do the same thing just because of a compiler issue... >> >> So I'm going to go with the plan of making an i386 and gcc compatible >> version... it'll still be a 4x+ performance over the existing code... >> This also means we could back port it to 9-stable if we wanted to... >> >> Thanks for the input... >> > > This also raises the interesting question of whether we want to bother > supporting things like AES-NI on i386 at all. It's a legacy/embedded > architecture at this point, in my opinion, and the people who run it > probably don't care about fancy new features like this. A related > question is whether we want to have any clang-only features in the kernel... It wasn't so much an issue of being clang-only, but rather the antique gcc+binutils not having full support on i386. The code would work fine with later versions of gcc/binutils, intel's compiler and clang. Just not with the old gcc + old binutils on i386. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV bitcoin:188ZjyYLFJiEheQZw4UtU27e2FMLmuRBUE From owner-freebsd-arch@FreeBSD.ORG Sun Jan 13 23:08:17 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6B9AEDA3; Sun, 13 Jan 2013 23:08:17 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) by mx1.freebsd.org (Postfix) with ESMTP id DA3F239A; Sun, 13 Jan 2013 23:08:16 +0000 (UTC) Received: by mail-we0-f177.google.com with SMTP id x48so1746083wey.8 for ; Sun, 13 Jan 2013 15:08:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=jyGikEVhy9pucrhkyPgi60xvyS3T/KfSJl6fp5maB64=; b=GURw/cZWAKTmu/FEfuDvcnf0T+KFqwNoJ+eGV+ECGwfQveaxEn8yiCaQglussn+boK X0uo8Q0AbAC9BCv+dhB1umft0mvTi1YQmagvH6Lf9FHFrqIeZRMLCXU3FhP40y8/3nLr TEH3HVsflPBdhvJ4r8CZe3w6soUtBUc9BT4PEDvEnTc5V8IW8Ga0u0oihf93iN1Ynb8N rbEn4lT5TNzTmzZF5d67B0HTzwpik3A/Em1Oi7Z/D5kuQEvKYWPD2voIOlu9Y8mMpQN8 Isk4rIOvHbSIihfFBTPSz8aS6iemfkoQGN2N0TPIAxNTR7lZmZ8m9LXuvZ3i8tJBS3jG CX1Q== MIME-Version: 1.0 Received: by 10.195.13.67 with SMTP id ew3mr44497796wjd.59.1358118495747; Sun, 13 Jan 2013 15:08:15 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Sun, 13 Jan 2013 15:08:15 -0800 (PST) In-Reply-To: <50F33B02.6040303@freebsd.org> References: <20130112233147.GK1410@funkthat.com> <20130113014242.GA61609@troutmask.apl.washington.edu> <20130113053725.GL1410@funkthat.com> <20130113202952.GO1410@funkthat.com> <20130113224800.GS1410@funkthat.com> <50F33B02.6040303@freebsd.org> Date: Sun, 13 Jan 2013 15:08:15 -0800 X-Google-Sender-Auth: xfqU5mT-RPdRRRItgbvJc8Z-Nso Message-ID: Subject: Re: how long to keep support for gcc on x86? From: Adrian Chadd To: Nathan Whitehorn Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 23:08:17 -0000 ... ? As an embedded platform, I'd expect that people will want to support any feature which dramatically boosts performance whilst reducing CPU. Also, if Intel decide to keep trying to push low power x86 for mobile applications, rather than ARM, x86 may just make a resurgence in places you once thought were servers. 32 bit x86 isn't legacy and won't be for a long time to come. Adrian From owner-freebsd-arch@FreeBSD.ORG Sun Jan 13 23:10:12 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2850BE4E; Sun, 13 Jan 2013 23:10:12 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 042FC3C8; Sun, 13 Jan 2013 23:10:04 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id r0DNA3Pj075876; Sun, 13 Jan 2013 16:10:04 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r0DNA1nf001260; Sun, 13 Jan 2013 16:10:01 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: [RFC/RFT] calloutng From: Ian Lepore To: Alexander Motin In-Reply-To: <50F30CAB.3000001@FreeBSD.org> References: <50CCAB99.4040308@FreeBSD.org> <50CE5B54.3050905@FreeBSD.org> <50D03173.9080904@FreeBSD.org> <20121225232126.GA47692@alchemy.franken.de> <50DB4EFE.2020600@FreeBSD.org> <20130106152313.GD26039@alchemy.franken.de> <50EBF921.2000304@FreeBSD.org> <20130113180940.GM26039@alchemy.franken.de> <50F30CAB.3000001@FreeBSD.org> Content-Type: text/plain; charset="us-ascii" Date: Sun, 13 Jan 2013 16:10:01 -0700 Message-ID: <1358118601.32417.41.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Davide Italiano , freebsd-arch@freebsd.org, FreeBSD Current , Marius Strobl X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 23:10:12 -0000 On Sun, 2013-01-13 at 21:36 +0200, Alexander Motin wrote: > On 13.01.2013 20:09, Marius Strobl wrote: [...] > > > > Uhm, there are no NMIs on sparc64. Does it make sense to bypass this > > adjustment on sparc64? > > If it is not possible or not good to to stop timer during programming, > there will always be some race window between code execution and timer > ticking. So some minimal safety range should be reserved. Though it > probably can be significantly reduced. In case of x86/HPET there is > additional factor of NMI, that extends race to unpredictable level and > so makes additional post-read almost mandatory. > > >> May be with rereading counter > >> after programming comparator (same as done for HPET, reading which is > >> probably much more expensive) this value could be reduced. > > > > I see. There are some bigger fish to fry at the moment though :) > Speaking of the HPET code, it seems to me that its restart logic can fire the same event twice. Is that harmless? -- Ian From owner-freebsd-arch@FreeBSD.ORG Sun Jan 13 23:18:38 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0C93A18D; Sun, 13 Jan 2013 23:18:38 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ea0-f175.google.com (mail-ea0-f175.google.com [209.85.215.175]) by mx1.freebsd.org (Postfix) with ESMTP id 4BD4461E; Sun, 13 Jan 2013 23:18:37 +0000 (UTC) Received: by mail-ea0-f175.google.com with SMTP id d1so300707eab.6 for ; Sun, 13 Jan 2013 15:18:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=GC8+rsuCb6k06K5jKC3zmOB0/sW2RHVaHFU6jwa6lrc=; b=iXLR8FWA1PNxzBvUMhT/VpU7Q1HYGwF9WvzAYltyiNOLEBWvSUIogIROHUrCuWR1KP SgtxmVUlocCKMb6sYb0TCEf+Be4lloq9J2smJVLR+7wgsg1aqnEWU6T3L7fWtw2JpyiM LbuBjUEcy/EwMT5pxBmCVZOxLDtTXUC7MVKZY7LDmQucSzq634Rdtz9HrNOH24ly4pPd xZc4k6T+/U7fcB9WiI/xAfJtEgP9Nj5Nww/fLuKKtvqQLaTmi8sXUHEYjGF3gzFVPwPs lSmsyNJTbVEriz+T+4fWJg8sZnzTbn+DaG3YDQ7t7bZynnieY8ebHkfCsvpOeM0JK8Qh lbdg== X-Received: by 10.14.219.72 with SMTP id l48mr225048018eep.37.1358119116209; Sun, 13 Jan 2013 15:18:36 -0800 (PST) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id f49sm19300520eep.12.2013.01.13.15.18.34 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 13 Jan 2013 15:18:35 -0800 (PST) Sender: Alexander Motin Message-ID: <50F340C8.2040905@FreeBSD.org> Date: Mon, 14 Jan 2013 01:18:32 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ian Lepore Subject: Re: [RFC/RFT] calloutng References: <50CCAB99.4040308@FreeBSD.org> <50CE5B54.3050905@FreeBSD.org> <50D03173.9080904@FreeBSD.org> <20121225232126.GA47692@alchemy.franken.de> <50DB4EFE.2020600@FreeBSD.org> <20130106152313.GD26039@alchemy.franken.de> <50EBF921.2000304@FreeBSD.org> <20130113180940.GM26039@alchemy.franken.de> <50F30CAB.3000001@FreeBSD.org> <1358118601.32417.41.camel@revolution.hippie.lan> In-Reply-To: <1358118601.32417.41.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Davide Italiano , freebsd-arch@freebsd.org, FreeBSD Current , Marius Strobl X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 23:18:38 -0000 On 14.01.2013 01:10, Ian Lepore wrote: > On Sun, 2013-01-13 at 21:36 +0200, Alexander Motin wrote: >> On 13.01.2013 20:09, Marius Strobl wrote: > [...] >>> >>> Uhm, there are no NMIs on sparc64. Does it make sense to bypass this >>> adjustment on sparc64? >> >> If it is not possible or not good to to stop timer during programming, >> there will always be some race window between code execution and timer >> ticking. So some minimal safety range should be reserved. Though it >> probably can be significantly reduced. In case of x86/HPET there is >> additional factor of NMI, that extends race to unpredictable level and >> so makes additional post-read almost mandatory. >> >>>> May be with rereading counter >>>> after programming comparator (same as done for HPET, reading which is >>>> probably much more expensive) this value could be reduced. >>> >>> I see. There are some bigger fish to fry at the moment though :) >> > > Speaking of the HPET code, it seems to me that its restart logic can > fire the same event twice. Is that harmless? It is much less harmful then not fire and loose interrupt completely, and as result stuck for indefinite time. I have no better ideas, while this seems works well. -- Alexander Motin From owner-freebsd-arch@FreeBSD.ORG Mon Jan 14 00:38:39 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9E13BDC0; Mon, 14 Jan 2013 00:38:39 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx08.syd.optusnet.com.au (fallbackmx08.syd.optusnet.com.au [211.29.132.10]) by mx1.freebsd.org (Postfix) with ESMTP id 730E686C; Mon, 14 Jan 2013 00:38:38 +0000 (UTC) Received: from mail35.syd.optusnet.com.au (mail35.syd.optusnet.com.au [211.29.133.51]) by fallbackmx08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id r0E0caxA016303; Mon, 14 Jan 2013 11:38:36 +1100 Received: from c211-30-173-106.carlnfd1.nsw.optusnet.com.au (c211-30-173-106.carlnfd1.nsw.optusnet.com.au [211.30.173.106]) by mail35.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id r0E0cKsQ030003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Jan 2013 11:38:22 +1100 Date: Mon, 14 Jan 2013 11:38:20 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Alexander Motin Subject: Re: [RFC/RFT] calloutng In-Reply-To: <50F30CAB.3000001@FreeBSD.org> Message-ID: <20130114102118.V1045@besplex.bde.org> References: <50CCAB99.4040308@FreeBSD.org> <50CE5B54.3050905@FreeBSD.org> <50D03173.9080904@FreeBSD.org> <20121225232126.GA47692@alchemy.franken.de> <50DB4EFE.2020600@FreeBSD.org> <20130106152313.GD26039@alchemy.franken.de> <50EBF921.2000304@FreeBSD.org> <20130113180940.GM26039@alchemy.franken.de> <50F30CAB.3000001@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=E6GVPthl c=1 sm=1 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=mUAV9h2nInsA:10 a=_g3VQHKJVn_i_Cvtq8kA:9 a=CjuIK1q_8ugA:10 a=TEtd8y5WR3g2ypngnwZWYw==:117 Cc: Davide Italiano , freebsd-arch@FreeBSD.org, FreeBSD Current , Marius Strobl X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 00:38:39 -0000 On Sun, 13 Jan 2013, Alexander Motin wrote: > On 13.01.2013 20:09, Marius Strobl wrote: >> On Tue, Jan 08, 2013 at 12:46:57PM +0200, Alexander Motin wrote: >>> On 06.01.2013 17:23, Marius Strobl wrote: >>>> I'm not really sure what to do about that. Earlier you already said >>>> that sched_bind(9) also isn't an option in case if td_critnest > 1. >>>> To be honest, I don't really unerstand why using a spin lock in the >>>> timecounter path makes sparc64 the only problematic architecture >>>> for your changes. The x86 i8254_get_timecount() also uses a spin lock >>>> so it should be in the same boat. >>> >>> The problem is not in using spinlock, but in waiting for other CPU while >>> spinlock is held. Other CPU may also hold spinlock and wait for >>> something, causing deadlock. i8254 code uses spinlock just to atomically >>> access hardware registers, so it causes no problems. >> >> Okay, but wouldn't that be a general problem then? Pretty much >> anything triggering an IPI holds smp_ipi_mtx while doing so and >> the lower level IPI stuff waits for other CPU(s), including on >> x86. > > The problem is general. But now it works because single smp_ipi_mtx is > used in all cases where IPI result is waited. As soon as spinning > happens with interrupts still enabled, there is no deadlocks. But > problem reappears if any different lock is used, or locks are nested. > > In existing code in HEAD and 9 timecounters are never called with spin > mutex held. I intentionally tried to avoid that in existing eventtimers > code. Er, timecounters are called with a spin mutex held in existing code: though it is dangerous to do so, timecounters are called from fast interrupt handlers for very timekeeping-critical purposes: - to implement the TIOCTIMESTAMP ioctl (except this is broken in -current). This was a primitive version of pps timestamping. - for pps timestamping. The interrupt handler (which should be a fast interrupt handler to minimize latency) calls pps_capture() which calls tc_get_timecount() and does other "lock-free" accesses to the timecounter state. This still works in -current (at least there is still code for it). OTOH, all drivers that call pps_capture() from their interrupt handler then immediately call pps_event(). This has always been very broken, and became even more broken with SMPng. pps_event() does many more timecounter and pps accesses whose locking is unclear at best, and in some configurations it calls hardpps(), which is only locked by Giant, despite comments in kern_ntptime.c still saying that it (and many other functions in kern_ntptime.c) must be called at splclock() or higher. splclock() is of course now null, but the locking requirements in kern_ntptime.c haven't changed much. kern_ntptime.c always needed to be locked by the equivalent of a spin mutex, which is stronger locking than was given by splclock(). pps_event() would have to aquire the spin mutex before calling hardpps(), although this is bad for fast interrupt handlers. The correct implementation is probably to only do the capture part from fast interrupt handlers. > Callout code same time can be called in any environment with any > locks held. And new callout code may need to know precise current time > in any of those conditions. Attempt to use an IPI and wait there can be > fatal. Callout code can't be called from such a general "any" environment as timecounter code. Not from a fast interrupt handler. Not from an NMI or IPI handler. I hope. But timecounter code has a good chance of working even for the last 2 environments, due to its design requirement of working in the first. The spinlock in the i8254 timecounter certainly breaks some cases. For example, suppose the lock is held for a timecounter read from normal context. It masks hardware interrupts on the current CPU (except in my version). It doesn't mask NMIs or other traps. So if the NMI or other trap handler does a timecounter hardware call, there is deadlock in at least the !SMP case. In my version, it blocks normal interrupts later if they occur, but doesn't block fast interrupts, so the pps_capture() call would deadlock if it occurs, like a timecounter call from an NMI. I avoid this by not using pps in any fast interrupt handler, and by only using the i8254 timecounter for testing. I do use pps in a (nonstandard) x86 RTC clock interrupt handler. My clock interrupt handlers are all non-fast to avoid this and other locking problems. >> FYI, these are the results of the v215 (btw., these (ab)use a bus >> cycle counter of the host-PCI-bridge as timecounter) with your >> calloutng_12_17.patch and kern.timecounter.alloweddeviation=0: >> select 1 23.82 >> poll 1 1008.23 >> usleep 1 23.31 >> nanosleep 1 23.17 >> kqueue 1 1010.35 >> kqueueto 1 26.26 >> syscall 1 1.91 >> select 300 307.72 >> poll 300 1008.23 >> usleep 300 307.64 >> nanosleep 300 23.21 Please fix the tv_nsec initialization so that we can see if nanosleep() and kqueue() work. (The nanosleep() timeout here is actually 300 nsec, so 23.21 usec being shorter than 300 usec is not a kernel bug.) >> kqueue 300 1010.49 >> kqueueto 300 26.27 >> syscall 300 1.92 >> ... > > It seems that extra delay is only about 10-17us. Sometimes only 7. But 23-26 for short timeouts. For long timeouts, it should be closer to 0 extra, since the overhead for scheduling and handling timer interrupts is smaller than the timeout so it can be subtracted from the timeout to get accuracy. Bruce From owner-freebsd-arch@FreeBSD.ORG Mon Jan 14 00:58:40 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 38F4B431 for ; Mon, 14 Jan 2013 00:58:40 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-vb0-f46.google.com (mail-vb0-f46.google.com [209.85.212.46]) by mx1.freebsd.org (Postfix) with ESMTP id BE127919 for ; Mon, 14 Jan 2013 00:58:39 +0000 (UTC) Received: by mail-vb0-f46.google.com with SMTP id b13so3078266vby.33 for ; Sun, 13 Jan 2013 16:58:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TRR0iPPWTYUm+FNBXt/AipbzcybhU4647kYICdn9WN0=; b=voxNPn3s0LjnAX8x8X6zZmSR7bXiN+Ku7zrqLgn4muANN+Wg22pcfWOA7uDb4jwQSO 3La1doIU33QhM9VddmZbeOSc8nSOlBiXglWvg0pBKJgCVVhAqMP836syHW5Z4TAxBjp1 qPBsMSrxc4GBQYQeYYypK23dneaHzaqs9fT38= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=TRR0iPPWTYUm+FNBXt/AipbzcybhU4647kYICdn9WN0=; b=fjHMQJzq2f8lCHsjIpNL+4q2AhDelb2SkWeChdhSlWSF/pDVVCXeZ7TvWFmnoDLTvb IKGVHWo8G1hK6HhCL5QtK/a1e+Hr4ayoksDf1EaTvouKCv2dztFrDLelUFRXcpBVGH66 q/hHZieXBPudEQhxgZBN2AOZZbc8XHvDs0+IvL/+zTF0TOxORLm4j6UOxAxbWvua7Uza EyxAuo9AmBuTVWB0B7fRKSx3Iy9FGnvEcNLdEGFXdpFfQU4TKQZSyOMmb63C9pegS8Fp 27JC46IYYnwEGgKH2CKWrgjglWkpG+XZgA6ixd8kswOkmLdAP1r60N1lRaOUAk5+0bNN 0tCw== MIME-Version: 1.0 Received: by 10.52.36.19 with SMTP id m19mr85987778vdj.33.1358125118560; Sun, 13 Jan 2013 16:58:38 -0800 (PST) Received: by 10.220.174.135 with HTTP; Sun, 13 Jan 2013 16:58:38 -0800 (PST) In-Reply-To: References: <20130112233147.GK1410@funkthat.com> <20130113014242.GA61609@troutmask.apl.washington.edu> <20130113053725.GL1410@funkthat.com> <20130113202952.GO1410@funkthat.com> <20130113224800.GS1410@funkthat.com> <50F33B02.6040303@freebsd.org> Date: Sun, 13 Jan 2013 16:58:38 -0800 Message-ID: Subject: Re: how long to keep support for gcc on x86? From: Peter Wemm To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQm1FktzGgDSOxKwE3gzQqyBXZCzYaj2L/96kFyfpDpr263TjMc8M5wmjH5zxj886k4BToLi Cc: Nathan Whitehorn , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 00:58:40 -0000 On Sun, Jan 13, 2013 at 3:08 PM, Adrian Chadd wrote: > ... ? > > As an embedded platform, I'd expect that people will want to support > any feature which dramatically boosts performance whilst reducing CPU. > > Also, if Intel decide to keep trying to push low power x86 for mobile > applications, rather than ARM, x86 may just make a resurgence in > places you once thought were servers. > > 32 bit x86 isn't legacy and won't be for a long time to come. Our buildworld environment and embedded $everything isn't well known for being embedded friendly. I'd wager that if somebody was trying to use an i386 kernel in an embedded device where every last thing counted, they'd be using an external toolchain targeted for their platform and some very selective cross-building. Compiler of $your_choice would be on the table if you were doing external compiling, and.. the default in-tree compiler does support AES-NI on both i386 and amd64, and the logical other choice (gcc-4.6+ and binutils) also does. The only question is whether to go out of our way to support an archaic, non-default compiler on one platform. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV bitcoin:188ZjyYLFJiEheQZw4UtU27e2FMLmuRBUE From owner-freebsd-arch@FreeBSD.ORG Mon Jan 14 02:52:04 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D4B40B78; Mon, 14 Jan 2013 02:52:04 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 390C3DB1; Mon, 14 Jan 2013 02:52:03 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id r0E2q2qh087965; Sun, 13 Jan 2013 19:52:02 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r0E2peZB001368; Sun, 13 Jan 2013 19:51:40 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: how long to keep support for gcc on x86? From: Ian Lepore To: Peter Wemm In-Reply-To: References: <20130112233147.GK1410@funkthat.com> <20130113014242.GA61609@troutmask.apl.washington.edu> <20130113053725.GL1410@funkthat.com> <20130113202952.GO1410@funkthat.com> <20130113224800.GS1410@funkthat.com> <50F33B02.6040303@freebsd.org> Content-Type: text/plain; charset="us-ascii" Date: Sun, 13 Jan 2013 19:51:40 -0700 Message-ID: <1358131900.32417.44.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , Nathan Whitehorn , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 02:52:04 -0000 On Sun, 2013-01-13 at 16:58 -0800, Peter Wemm wrote: > On Sun, Jan 13, 2013 at 3:08 PM, Adrian Chadd wrote: > > ... ? > > > > As an embedded platform, I'd expect that people will want to support > > any feature which dramatically boosts performance whilst reducing CPU. > > > > Also, if Intel decide to keep trying to push low power x86 for mobile > > applications, rather than ARM, x86 may just make a resurgence in > > places you once thought were servers. > > > > 32 bit x86 isn't legacy and won't be for a long time to come. > > Our buildworld environment and embedded $everything isn't well known > for being embedded friendly. I'd wager that if somebody was trying to > use an i386 kernel in an embedded device where every last thing > counted, they'd be using an external toolchain targeted for their > platform and some very selective cross-building. Compiler of > $your_choice would be on the table if you were doing external > compiling, and.. the default in-tree compiler does support AES-NI on > both i386 and amd64, and the logical other choice (gcc-4.6+ and > binutils) also does. Ummm. Search for "industrial single board computer." They're not rare. Lots of us build products around them. Some of us use FreeBSD to do so, with the stock toolchain. I sure hope support for 32 bit x86 isn't fading away any time soon. -- Ian From owner-freebsd-arch@FreeBSD.ORG Mon Jan 14 03:08:49 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E5E31FA5; Mon, 14 Jan 2013 03:08:49 +0000 (UTC) (envelope-from ike@blackskyresearch.net) Received: from rs149.luxsci.com (rs149.luxsci.com [64.49.224.181]) by mx1.freebsd.org (Postfix) with ESMTP id B1924EE8; Mon, 14 Jan 2013 03:08:49 +0000 (UTC) Received: from rs149.luxsci.com (localhost.localdomain [127.0.0.1]) by rs149.luxsci.com (8.14.4/8.13.8) with ESMTP id r0E32nsO009386; Sun, 13 Jan 2013 22:02:49 -0500 Received: (from root@localhost) by rs149.luxsci.com (8.14.4/8.13.8/Submit) id r0E322Z6008938; Mon, 14 Jan 2013 03:02:02 GMT Received: (from sender 74627) (rs149.luxsci.com [127.0.0.1]) by LuxSci SP; Mon, 14 Jan 2013 03:02:02 +0000 Subject: Re: how long to keep support for gcc on x86? Content-Type: text/plain; charset=us-ascii From: "Isaac (.ike) Levy" In-Reply-To: Date: Sun, 13 Jan 2013 22:01:54 -0500 Content-Transfer-Encoding: quoted-printable References: <20130112233147.GK1410@funkthat.com> <20130113014242.GA61609@troutmask.apl.washington.edu> <20130113053725.GL1410@funkthat.com> <20130113202952.GO1410@funkthat.com> <20130113224800.GS1410@funkthat.com> <50F33B02.6040303@freebsd.org> To: Peter Wemm X-Lux-Comment: Message r0E31thR008892 sent by user #74627 Message-Id: <1358132522-7259997.45478983.fr0E31thR008892@rs149.luxsci.com> X-Comment: LuxSci SP Message ID - 1358132522-7259997.45478983 Cc: Adrian Chadd , Nathan Whitehorn , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 03:08:50 -0000 On Jan 13, 2013, at 7:58 PM, Peter Wemm wrote: > On Sun, Jan 13, 2013 at 3:08 PM, Adrian Chadd = wrote: >> ... ? >>=20 >> As an embedded platform, I'd expect that people will want to support >> any feature which dramatically boosts performance whilst reducing = CPU. >>=20 >> Also, if Intel decide to keep trying to push low power x86 for mobile >> applications, rather than ARM, x86 may just make a resurgence in >> places you once thought were servers. >>=20 >> 32 bit x86 isn't legacy and won't be for a long time to come. >=20 > Our buildworld environment and embedded $everything isn't well known > for being embedded friendly. =20 IMHO, I believe the buildworld environment is quite friendly, but I = don't have anything except FreeBSD and OpenBSD to compare it to, > I'd wager that if somebody was trying to > use an i386 kernel in an embedded device where every last thing > counted, they'd be using an external toolchain targeted for their > platform and some very selective cross-building. =20 I'll take your wager- I'm one of those guys, lots of embedded FreeBSD on = tiny hardware- but I haven't been using any external toolchain or = compiler. Your wager may still be rational, your case is plausable, but since = 2004, I (and dozens of colleagues/friends/hackers) happily been = compiling FreeBSD, using zero add-on tools. (I've used a lot of Soekris = 4801 and 5501, and ALIX alix2d3 embedded boards). Typical Kernel and = world take approximately 18+ hours to build on a 4801, depending on the = kernel conf. Beyond Soekris and PcEngines, there is a glut of relevant industrial = single-board/embedded/funky hardware that is also 32 bit x86- some = pretty amazing gear, at varying levels of cost. The only port (external toolchain) I've installed on a build box was = dtach and sudo, (neither of which are obviously considered build = toolchain type utilities). I actually *enjoy* naked FreeBSD on these = platforms- no ports, no fluff, 500+ utilities in /bin and /usr/bin is = plenty of software to me :) FreeBSD kernel has had rock-solid support for these boards, http://wiki.soekris.info/Installing_FreeBSD Even the nanobsd build framework complements the soekris-specific = kernel/world build support nicely. > Compiler of > $your_choice would be on the table if you were doing external > compiling, and.. the default in-tree compiler does support AES-NI on > both i386 and amd64, and the logical other choice (gcc-4.6+ and > binutils) also does. External compiling is indeed possible, however, I've found it much = simpler for my purposes to simply build on the machine itself. (At the = end of the day, the apps I'm running have to *run* on the box, and if = they're too fat to compile there, my experience is that should set rough = expectations for how well the software will actually perform on the = platforms) > The only question is whether to go out of our way to support an > archaic, non-default compiler on one platform. I may be missing the point, I'm just a sysadmin who hacks in userland, = but 32 bit x86 doesn't seem to be disappearing any time soon. One more relevant use: Beyond the real possibility of more 32 bit x86 as = ARM competition, with the glut of 32 bit x86 'server' hardware I touch = in datacenters, much of it that crosses my hands will end up being "put = out to pasture" on the perimeter as FreeBSD network appliances, where it = can still shine rockin' PF/CARP/etc until the hardware completely dies. And relevant: the PfSense installed base: lots of 32 bit x86 hardware = (tons of SOHO routers on embedded boards, along with bigger kit in = datacenters). Best, .ike From owner-freebsd-arch@FreeBSD.ORG Mon Jan 14 03:12:19 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 39DBE109; Mon, 14 Jan 2013 03:12:19 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from agogare.doit.wisc.edu (agogare.doit.wisc.edu [144.92.197.211]) by mx1.freebsd.org (Postfix) with ESMTP id E4BBAF03; Mon, 14 Jan 2013 03:12:18 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from avs-daemon.smtpauth2.wiscmail.wisc.edu by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0MGL00002I8HHI00@smtpauth2.wiscmail.wisc.edu>; Sun, 13 Jan 2013 21:12:17 -0600 (CST) Received: from wanderer.tachypleus.net (c-24-63-204-107.hsd1.ct.comcast.net [24.63.204.107]) by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0MGL00KBMI8FLS10@smtpauth2.wiscmail.wisc.edu>; Sun, 13 Jan 2013 21:12:16 -0600 (CST) Date: Sun, 13 Jan 2013 19:12:14 -0800 From: Nathan Whitehorn Subject: Re: how long to keep support for gcc on x86? In-reply-to: Sender: whitehorn@wisc.edu To: Adrian Chadd Message-id: <50F3778E.8020803@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=24.63.204.107 X-Spam-PmxInfo: Server=avs-14, Version=5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.1.14.30317, SenderIP=24.63.204.107 References: <20130112233147.GK1410@funkthat.com> <20130113014242.GA61609@troutmask.apl.washington.edu> <20130113053725.GL1410@funkthat.com> <20130113202952.GO1410@funkthat.com> <20130113224800.GS1410@funkthat.com> <50F33B02.6040303@freebsd.org> User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130112 Thunderbird/17.0.2 Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 03:12:19 -0000 On 01/13/13 15:08, Adrian Chadd wrote: > ... ? > > As an embedded platform, I'd expect that people will want to support > any feature which dramatically boosts performance whilst reducing CPU. > > Also, if Intel decide to keep trying to push low power x86 for mobile > applications, rather than ARM, x86 may just make a resurgence in > places you once thought were servers. > > 32 bit x86 isn't legacy and won't be for a long time to come. > My point was that, for now at least, the systems on which people run i386 kernels are not ones that even have AES-NI, so not worrying about it on i386 for the time being seems reasonable. -Nathan From owner-freebsd-arch@FreeBSD.ORG Mon Jan 14 03:56:49 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 81A7975A for ; Mon, 14 Jan 2013 03:56:49 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-vb0-f50.google.com (mail-vb0-f50.google.com [209.85.212.50]) by mx1.freebsd.org (Postfix) with ESMTP id 3E336FFC for ; Mon, 14 Jan 2013 03:56:49 +0000 (UTC) Received: by mail-vb0-f50.google.com with SMTP id ft2so3112201vbb.23 for ; Sun, 13 Jan 2013 19:56:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=G2RBvgyFUhHQTAraTfXe/+n239lPjGgcvIlCpLJfgaE=; b=1OUVKCQtwBmWPWuDM7EAnqlEQFVN+CbPF5J5cjF/E7I8n5kRPTbEspFt4piGwb4t2B URTOl01lAIJcMDdm7/52PHiTlOJa4HrvG9J+SyBx2GVcohiZh7K1FgxLuyW1fut7FtIl 7E5LKfUMe5RTeVsH01/RRwsjepkolSPuUjnsM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=G2RBvgyFUhHQTAraTfXe/+n239lPjGgcvIlCpLJfgaE=; b=Lrp3Astpuzo/U0OI/bxBNKTmE8EWftrSCNWxO6JjkRwLyfJuaBjzvKW4IyRkbENAln 2IjC4i8pZOpDaFltC/Fg89MOl7P/z5rVRq7Rh6la1rjkpmC5hDqWunXEA/Je5AQzzHb0 lhytz9h4vy5aNikmDaAktxa6e3gWbdgOvm31rIwyDALW/9/yDe4Xww8PR/e1r3EPbRqg NCSSmVcw/1vWN06aSwXtNH4O1r3vjJNdVtmCZwMS3uXDEFn5dSO+euUMptU3x+CYakjY fKiiNmYmGCklpRVKD/Il8o9Kqlowv8n8Y5SRnGPkYxH9z1qymTcebEY1kQai0qbG/zPA 1exA== MIME-Version: 1.0 Received: by 10.220.238.146 with SMTP id ks18mr11941185vcb.58.1358135807443; Sun, 13 Jan 2013 19:56:47 -0800 (PST) Received: by 10.220.174.135 with HTTP; Sun, 13 Jan 2013 19:56:47 -0800 (PST) In-Reply-To: <1358131900.32417.44.camel@revolution.hippie.lan> References: <20130112233147.GK1410@funkthat.com> <20130113014242.GA61609@troutmask.apl.washington.edu> <20130113053725.GL1410@funkthat.com> <20130113202952.GO1410@funkthat.com> <20130113224800.GS1410@funkthat.com> <50F33B02.6040303@freebsd.org> <1358131900.32417.44.camel@revolution.hippie.lan> Date: Sun, 13 Jan 2013 19:56:47 -0800 Message-ID: Subject: Re: how long to keep support for gcc on x86? From: Peter Wemm To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQngTY1VGDuwKa9S+8IF6Gc7nBGTRTTx5QVLrBacVwTnAcQ2dwoLE6qrklrCRodK5rl0jt1L Cc: Adrian Chadd , Nathan Whitehorn , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 03:56:49 -0000 On Sun, Jan 13, 2013 at 6:51 PM, Ian Lepore wrote: > On Sun, 2013-01-13 at 16:58 -0800, Peter Wemm wrote: >> On Sun, Jan 13, 2013 at 3:08 PM, Adrian Chadd wrote: >> > ... ? >> > >> > As an embedded platform, I'd expect that people will want to support >> > any feature which dramatically boosts performance whilst reducing CPU. >> > >> > Also, if Intel decide to keep trying to push low power x86 for mobile >> > applications, rather than ARM, x86 may just make a resurgence in >> > places you once thought were servers. >> > >> > 32 bit x86 isn't legacy and won't be for a long time to come. >> >> Our buildworld environment and embedded $everything isn't well known >> for being embedded friendly. I'd wager that if somebody was trying to >> use an i386 kernel in an embedded device where every last thing >> counted, they'd be using an external toolchain targeted for their >> platform and some very selective cross-building. Compiler of >> $your_choice would be on the table if you were doing external >> compiling, and.. the default in-tree compiler does support AES-NI on >> both i386 and amd64, and the logical other choice (gcc-4.6+ and >> binutils) also does. > > Ummm. Search for "industrial single board computer." They're not rare. > Lots of us build products around them. Some of us use FreeBSD to do so, > with the stock toolchain. I sure hope support for 32 bit x86 isn't > fading away any time soon. I had a quick look. Yes, there were quite a few devices, but I didn't find any 32bit-only that had AES-NI. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV bitcoin:188ZjyYLFJiEheQZw4UtU27e2FMLmuRBUE From owner-freebsd-arch@FreeBSD.ORG Mon Jan 14 03:59:09 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7F82E815 for ; Mon, 14 Jan 2013 03:59:09 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-vb0-f45.google.com (mail-vb0-f45.google.com [209.85.212.45]) by mx1.freebsd.org (Postfix) with ESMTP id F157871 for ; Mon, 14 Jan 2013 03:59:08 +0000 (UTC) Received: by mail-vb0-f45.google.com with SMTP id p1so3140843vbi.18 for ; Sun, 13 Jan 2013 19:59:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=XD/wtNEV1oI9lb/T2js0IBWAGCIgqSfaw5dxXOYKt8k=; b=BkLPwvVeBLpdFKja2ejNkZ23Owixz11H+x3kA8wzL0+EV4eLsJ2OuPNLY4ZYtXhvQ4 7151qb8cm58BGnm1kuZCe63rqZcO25DKzHEW7Zqbs8b3e6lYWllyAcOqnYPVvk5WAaM/ IAEbY4T1EMmkUsNStCyQDbSXdjBhvVZUheIMU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=XD/wtNEV1oI9lb/T2js0IBWAGCIgqSfaw5dxXOYKt8k=; b=lkmP4lN/60SG1kFkpKJRovto6YWzwe4qs0+ktrEfMPIgLeKUj5DR7WaemNqMuyGi07 Yn7h20eEh3zA7VOHfi1mGf6/v3OF7Zd7SWXgnjI+E72o7xhW/82G2qzy01X143N+eXhR 2Cx3eXkmABMOGkblGgQE7nPJqdrmLweeFh85aIa8LEjFCTsGC/r71fIspd7Fpyt9Oiid QJ/0VE4sSrSs1gtCPZ+NMXhvhS/ThrfjjJ9bySyCvHFgNp/y7vBC9Yc8OePLF2nR20lD a3ss1XlfFHHalMbMGaZ9GvQC6k1tqGg0duu3KkxXsGy8uxhmb6yrblaRnm3hTxGE8+ly skhQ== MIME-Version: 1.0 Received: by 10.58.134.16 with SMTP id pg16mr19909075veb.12.1358135941707; Sun, 13 Jan 2013 19:59:01 -0800 (PST) Received: by 10.220.174.135 with HTTP; Sun, 13 Jan 2013 19:59:01 -0800 (PST) In-Reply-To: <1358132522-7259997.45478983.fr0E31thR008892@rs149.luxsci.com> References: <20130112233147.GK1410@funkthat.com> <20130113014242.GA61609@troutmask.apl.washington.edu> <20130113053725.GL1410@funkthat.com> <20130113202952.GO1410@funkthat.com> <20130113224800.GS1410@funkthat.com> <50F33B02.6040303@freebsd.org> <1358132522-7259997.45478983.fr0E31thR008892@rs149.luxsci.com> Date: Sun, 13 Jan 2013 19:59:01 -0800 Message-ID: Subject: Re: how long to keep support for gcc on x86? From: Peter Wemm To: "Isaac (.ike) Levy" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlYcFXRaIUcLoRoDGZebjQj0O1ZyLFMyy0V+IaYR6KR8WBdA2vr3uaivueBU7JUjQR0B+/V Cc: Adrian Chadd , Nathan Whitehorn , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 03:59:09 -0000 On Sun, Jan 13, 2013 at 7:01 PM, Isaac (.ike) Levy wrote: > On Jan 13, 2013, at 7:58 PM, Peter Wemm wrote: >> On Sun, Jan 13, 2013 at 3:08 PM, Adrian Chadd wrote= : >>> ... ? >>> >>> As an embedded platform, I'd expect that people will want to support >>> any feature which dramatically boosts performance whilst reducing CPU. >>> >>> Also, if Intel decide to keep trying to push low power x86 for mobile >>> applications, rather than ARM, x86 may just make a resurgence in >>> places you once thought were servers. >>> >>> 32 bit x86 isn't legacy and won't be for a long time to come. >> >> Our buildworld environment and embedded $everything isn't well known >> for being embedded friendly. > > IMHO, I believe the buildworld environment is quite friendly, but I don't= have anything except FreeBSD and OpenBSD to compare it to, > >> I'd wager that if somebody was trying to >> use an i386 kernel in an embedded device where every last thing >> counted, they'd be using an external toolchain targeted for their >> platform and some very selective cross-building. > > I'll take your wager- I'm one of those guys, lots of embedded FreeBSD on = tiny hardware- but I haven't been using any external toolchain or compiler. > > Your wager may still be rational, your case is plausable, but since 2004,= I (and dozens of colleagues/friends/hackers) happily been compiling FreeBS= D, using zero add-on tools. (I've used a lot of Soekris 4801 and 5501, and = ALIX alix2d3 embedded boards). Typical Kernel and world take approximately= 18+ hours to build on a 4801, depending on the kernel conf. > > Beyond Soekris and PcEngines, there is a glut of relevant industrial sing= le-board/embedded/funky hardware that is also 32 bit x86- some pretty amazi= ng gear, at varying levels of cost. Sure, but how many of these have the new AES-NI stuff? And even if they did, the default 10.x compiler would support it. --=20 Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV bitcoin:188ZjyYLFJiEheQZw4UtU27e2FMLmuRBUE From owner-freebsd-arch@FreeBSD.ORG Mon Jan 14 04:38:52 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 93EC6C2F; Mon, 14 Jan 2013 04:38:52 +0000 (UTC) (envelope-from ike@blackskyresearch.net) Received: from rs149.luxsci.com (rs149.luxsci.com [64.49.224.181]) by mx1.freebsd.org (Postfix) with ESMTP id 42F5F120; Mon, 14 Jan 2013 04:38:51 +0000 (UTC) Received: from rs149.luxsci.com (localhost.localdomain [127.0.0.1]) by rs149.luxsci.com (8.14.4/8.13.8) with ESMTP id r0E4coFZ013476; Sun, 13 Jan 2013 23:38:50 -0500 Received: (from root@localhost) by rs149.luxsci.com (8.14.4/8.13.8/Submit) id r0E4c2g9011969; Mon, 14 Jan 2013 04:38:02 GMT Received: (from sender 74627) (rs149.luxsci.com [127.0.0.1]) by LuxSci SP; Mon, 14 Jan 2013 04:38:02 +0000 Subject: Re: how long to keep support for gcc on x86? Content-Type: text/plain; charset=windows-1252 From: "Isaac (.ike) Levy" In-Reply-To: Date: Sun, 13 Jan 2013 23:37:10 -0500 Content-Transfer-Encoding: quoted-printable References: <20130112233147.GK1410@funkthat.com> <20130113014242.GA61609@troutmask.apl.washington.edu> <20130113053725.GL1410@funkthat.com> <20130113202952.GO1410@funkthat.com> <20130113224800.GS1410@funkthat.com> <50F33B02.6040303@freebsd.org> <1358132522-7259997.45478983.fr0E31thR008892@rs149.luxsci.com> To: Peter Wemm X-Lux-Comment: Message r0E4bAqb011623 sent by user #74627 Message-Id: <1358138282-2386446.18050069.fr0E4bAqb011623@rs149.luxsci.com> X-Comment: LuxSci SP Message ID - 1358138282-2386446.18050069 Cc: Adrian Chadd , Nathan Whitehorn , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 04:38:52 -0000 On Jan 13, 2013, at 10:59 PM, Peter Wemm wrote: >> 32 bit x86 >=20 > Sure, but how many of these have the new AES-NI stuff? Hrm, I *believe* the Geode CPU's on a number of the PcEngines ALIX = boards actually do, and the Soekris 5501 seems to as well. > And even if they did, the default 10.x compiler would support it. Can't confirm that (yet), but I'll bet it's AOK. -- On Jan 13, 2013, at 2:30 PM, Warner Losh wrote: >> Please also note that people can and will compile FreeBSD on a >> non-default-system compiler ; so deprecating gcc (either support or >> framework) should be considered carefully. >=20 >=20 > When this was talked about at the clang summit, the overwhelming = opinion expressed was "better with clang". Those words made this sysadmin very, very happy. I'm so excited using = clang and want it everywhere, but I also like sleeping at night while we = get there. > If you can make things better with clang, great. However, gcc still = must work. Along the "better with clang" lines, it seems reasonable enough that: - this new AES-NI functionality could build under clang, if, - the new AES-NI functionality could merely not build under gcc, yet gcc = still yields a functional kernel/world/etc=85 Is this bad, bending "better with clang" stick, or is this a reasonable = move, in the right spirit? It's not like a popular ethernet interface = won't compile... Best, .ike From owner-freebsd-arch@FreeBSD.ORG Mon Jan 14 05:27:41 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2EFED1B4 for ; Mon, 14 Jan 2013 05:27:41 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-vc0-f175.google.com (mail-vc0-f175.google.com [209.85.220.175]) by mx1.freebsd.org (Postfix) with ESMTP id CD76721C for ; Mon, 14 Jan 2013 05:27:40 +0000 (UTC) Received: by mail-vc0-f175.google.com with SMTP id fy7so3147374vcb.20 for ; Sun, 13 Jan 2013 21:27:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ynYhj9trVkxN3sGIYIimHx2zqUJwNiJU2xCjP6LMDpY=; b=0tI2yY210BcJRz8iyMjs+G1uMNWA/KXHYWiIK3vLEpkSqk3AUAGhBh0MDaYZQDw3VJ DSqiNkb+yuYGxi/2RXOUgzZ2tIbUbdC6rCxzuHLm1qlgH5lzguRC0VylfcAaV9WB1QPj nOZP/ZmgMoTkY6jLs+jceYO2nGvImkdbwMb1g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=ynYhj9trVkxN3sGIYIimHx2zqUJwNiJU2xCjP6LMDpY=; b=DIHmVLBf4nX+L2mTKIecwckeyBFKZJdM0QKW6CAN3zZOfRgMPrJWvQt6SZ+kp5bbCH eGDZjzyecPS3j1xLqsKhi408l+LFkE10JvV9DqhsjV6JnWyIUnE0zaN4KcRs9EzG0zlq nbf8aVXQId9rALxwtARUm/tSobpIX70neUKaIEXYoFvgAHVgu2iwmST4p/TWQuiPmmmm nKZAI2EFCysATgnIh9iX2W8Lx3sBfAYiA5MxLnAD8I8ZmDRhsCPsTDNhEkZxlX+KLPaX gkYGGsDRbvhbuMEq3Hm904+mkOvOVHdHJn0JVgaCnVrCx6YQkWNqkccX+LQkN3fkg+en pOag== MIME-Version: 1.0 Received: by 10.220.107.5 with SMTP id z5mr101377568vco.22.1358141259975; Sun, 13 Jan 2013 21:27:39 -0800 (PST) Received: by 10.220.174.135 with HTTP; Sun, 13 Jan 2013 21:27:39 -0800 (PST) In-Reply-To: <1358138282-2386446.18050069.fr0E4bAqb011623@rs149.luxsci.com> References: <20130112233147.GK1410@funkthat.com> <20130113014242.GA61609@troutmask.apl.washington.edu> <20130113053725.GL1410@funkthat.com> <20130113202952.GO1410@funkthat.com> <20130113224800.GS1410@funkthat.com> <50F33B02.6040303@freebsd.org> <1358132522-7259997.45478983.fr0E31thR008892@rs149.luxsci.com> <1358138282-2386446.18050069.fr0E4bAqb011623@rs149.luxsci.com> Date: Sun, 13 Jan 2013 21:27:39 -0800 Message-ID: Subject: Re: how long to keep support for gcc on x86? From: Peter Wemm To: "Isaac (.ike) Levy" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkR1Ihts19cz7NAddBzF327kmdz4ZOOODbSR03uXdiikzIwkmJI/S3PvCiImIUhuwLA2Xsp Cc: Adrian Chadd , Nathan Whitehorn , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 05:27:41 -0000 On Sun, Jan 13, 2013 at 8:37 PM, Isaac (.ike) Levy wrote: > On Jan 13, 2013, at 10:59 PM, Peter Wemm wrote: >>> 32 bit x86 >> >> Sure, but how many of these have the new AES-NI stuff? > > Hrm, I *believe* the Geode CPU's on a number of the PcEngines ALIX boards actually do, and the Soekris 5501 seems to as well. Nope. They have AES on the die, but its not the AES-NI that's the topic here. AES-NI was added in 2010 in the Core-i5/i7 families and in 2012 in the AMD A10 cores. >> And even if they did, the default 10.x compiler would support it. > > Can't confirm that (yet), but I'll bet it's AOK. That's how this thread started. Full AES-NI support is in the default compiler (clang) in the base system for amd64 and i386 but there's missing pieces with the old built-in gcc+binutils. If you BYO newer version of gcc+binutils, that would work too. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV bitcoin:188ZjyYLFJiEheQZw4UtU27e2FMLmuRBUE From owner-freebsd-arch@FreeBSD.ORG Mon Jan 14 05:38:52 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C721936A; Mon, 14 Jan 2013 05:38:52 +0000 (UTC) (envelope-from ike@blackskyresearch.net) Received: from rs149.luxsci.com (rs149.luxsci.com [64.49.224.181]) by mx1.freebsd.org (Postfix) with ESMTP id 7C65326E; Mon, 14 Jan 2013 05:38:51 +0000 (UTC) Received: from rs149.luxsci.com (localhost.localdomain [127.0.0.1]) by rs149.luxsci.com (8.14.4/8.13.8) with ESMTP id r0E5coeY001866; Mon, 14 Jan 2013 00:38:50 -0500 Received: (from root@localhost) by rs149.luxsci.com (8.14.4/8.13.8/Submit) id r0E5c2FD001438; Mon, 14 Jan 2013 05:38:02 GMT Received: (from sender 74627) (rs149.luxsci.com [127.0.0.1]) by LuxSci SP; Mon, 14 Jan 2013 05:38:02 +0000 Subject: Re: how long to keep support for gcc on x86? Content-Type: text/plain; charset=us-ascii From: "Isaac (.ike) Levy" In-Reply-To: Date: Mon, 14 Jan 2013 00:37:50 -0500 Content-Transfer-Encoding: quoted-printable References: <20130112233147.GK1410@funkthat.com> <20130113014242.GA61609@troutmask.apl.washington.edu> <20130113053725.GL1410@funkthat.com> <20130113202952.GO1410@funkthat.com> <20130113224800.GS1410@funkthat.com> <50F33B02.6040303@freebsd.org> <1358132522-7259997.45478983.fr0E31thR008892@rs149.luxsci.com> <1358138282-2386446.18050069.fr0E4bAqb011623@rs149.luxsci.com> To: Peter Wemm X-Lux-Comment: Message r0E5boZM001313 sent by user #74627 Message-Id: <1358141882-9913399.7005672.fr0E5boZM001313@rs149.luxsci.com> X-Comment: LuxSci SP Message ID - 1358141882-9913399.7005672 Cc: Adrian Chadd , Nathan Whitehorn , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 05:38:52 -0000 On Jan 14, 2013, at 12:27 AM, Peter Wemm wrote: >> Hrm, I *believe* the Geode CPU's on a number of the PcEngines ALIX = boards actually do, and the Soekris 5501 seems to as well. >=20 > Nope. They have AES on the die, but its not the AES-NI that's the > topic here. AES-NI was added in 2010 in the Core-i5/i7 families and > in 2012 in the AMD A10 cores. 10-4, thanks for the clarification. >>> And even if they did, the default 10.x compiler would support it. >>=20 >> Can't confirm that (yet), but I'll bet it's AOK. >=20 > That's how this thread started. Full AES-NI support is in the default > compiler (clang) in the base system for amd64 and i386 but there's > missing pieces with the old built-in gcc+binutils. If you BYO newer > version of gcc+binutils, that would work too. I'll step back on this one for the right call. Best, .ike From owner-freebsd-arch@FreeBSD.ORG Mon Jan 14 14:56:28 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 38F3A57B; Mon, 14 Jan 2013 14:56:28 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id C39A7D9A; Mon, 14 Jan 2013 14:56:27 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id r0EEuKQm028038; Mon, 14 Jan 2013 07:56:21 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r0EEuIUV002126; Mon, 14 Jan 2013 07:56:18 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: how long to keep support for gcc on x86? From: Ian Lepore To: Peter Wemm In-Reply-To: References: <20130112233147.GK1410@funkthat.com> <20130113014242.GA61609@troutmask.apl.washington.edu> <20130113053725.GL1410@funkthat.com> <20130113202952.GO1410@funkthat.com> <20130113224800.GS1410@funkthat.com> <50F33B02.6040303@freebsd.org> <1358131900.32417.44.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Mon, 14 Jan 2013 07:56:18 -0700 Message-ID: <1358175378.32417.49.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , Nathan Whitehorn , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 14:56:28 -0000 On Sun, 2013-01-13 at 19:56 -0800, Peter Wemm wrote: > On Sun, Jan 13, 2013 at 6:51 PM, Ian Lepore > wrote: > > On Sun, 2013-01-13 at 16:58 -0800, Peter Wemm wrote: > >> On Sun, Jan 13, 2013 at 3:08 PM, Adrian Chadd wrote: > >> > ... ? > >> > > >> > As an embedded platform, I'd expect that people will want to support > >> > any feature which dramatically boosts performance whilst reducing CPU. > >> > > >> > Also, if Intel decide to keep trying to push low power x86 for mobile > >> > applications, rather than ARM, x86 may just make a resurgence in > >> > places you once thought were servers. > >> > > >> > 32 bit x86 isn't legacy and won't be for a long time to come. > >> > >> Our buildworld environment and embedded $everything isn't well known > >> for being embedded friendly. I'd wager that if somebody was trying to > >> use an i386 kernel in an embedded device where every last thing > >> counted, they'd be using an external toolchain targeted for their > >> platform and some very selective cross-building. Compiler of > >> $your_choice would be on the table if you were doing external > >> compiling, and.. the default in-tree compiler does support AES-NI on > >> both i386 and amd64, and the logical other choice (gcc-4.6+ and > >> binutils) also does. > > > > Ummm. Search for "industrial single board computer." They're not rare. > > Lots of us build products around them. Some of us use FreeBSD to do so, > > with the stock toolchain. I sure hope support for 32 bit x86 isn't > > fading away any time soon. > > I had a quick look. Yes, there were quite a few devices, but I didn't > find any 32bit-only that had AES-NI. Ah, I guess I misunderstood the point. Talk of removing gcc support just because clang is available is still a bit scary to me. I anticipate using gcc for quite a while, waiting for the rest of the world to shake out the obscure clang bugs (I'll be doing my part to shake out bugs elsewhere in the system). I'm not a huge gcc fan so much as it being "the devil I know." It's hard enough bringing up new software on new hardware; if you have to start suspecting unknown bugs in your toolchain as well it becomes an intractable problem. -- Ian From owner-freebsd-arch@FreeBSD.ORG Mon Jan 14 15:09:02 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D9FC0CD4 for ; Mon, 14 Jan 2013 15:09:02 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 145AFE72 for ; Mon, 14 Jan 2013 15:09:01 +0000 (UTC) Received: (qmail 61629 invoked from network); 14 Jan 2013 16:31:55 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 14 Jan 2013 16:31:55 -0000 Message-ID: <50F41F8C.5030900@freebsd.org> Date: Mon, 14 Jan 2013 16:09:00 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Alfred Perlstein Subject: Re: svn commit: r243631 - in head/sys: kern sys References: <201211272119.qARLJxXV061083@svn.freebsd.org> <50C1BC90.90106@freebsd.org> <50C25A27.4060007@bluezbox.com> <50C26331.6030504@freebsd.org> <50C26AE9.4020600@bluezbox.com> <50C3A3D3.9000804@freebsd.org> <50C3AF72.4010902@rice.edu> <330405A1-312A-45A5-BB86-4969478D8BBD@bluezbox.com> <50D03E83.8060908@rice.edu> <50DD081E.8000409@bluezbox.com> <50EB1841.5030006@bluezbox.com> <50EB22D2.6090103@rice.edu> <50EB415F.8020405@freebsd.org> <50F04FE5.7010406@rice.edu> <50F1BD69.4060104@mu.org> <50F2F79C.7040109@mu.org> In-Reply-To: <50F2F79C.7040109@mu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , src-committers@freebsd.org, Alan Cox , "Jayachandran C." , svn-src-all@freebsd.org, Oleksandr Tymoshenko , freebsd-arch@freebsd.org, svn-src-head@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 15:09:02 -0000 On 13.01.2013 19:06, Alfred Perlstein wrote: > On 1/12/13 10:32 PM, Adrian Chadd wrote: >> On 12 January 2013 11:45, Alfred Perlstein wrote: >> >>> I'm not sure if regressing to the waterfall method of development is a good >>> idea at this point. >>> >>> I see a light at the end of the tunnel and we to continue to just handle >>> these minor corner cases as we progress. >>> >>> If we move to a model where a minor bug is grounds to completely remove >>> helpful code then nothing will ever get done. >>> >> Allocating 512MB worth of callwheels on a 16GB MIPS machine is a >> little silly, don't you think? >> >> That suggests to me that the extent of which maxfiles/maxusers/etc >> percolates the codebase wasn't totally understood by those who wish to >> change it. >> >> I'd rather see some more investigative work into outlining things that >> need fixing and start fixing those, rather than "just change stuff and >> fix whatever issues creep up." >> >> I kinda hope we all understand what we're working on in the kernel a >> little better than that. > > Cool! I'm glad people are now aware of the callwheel allocation being insane with large maxusers. > > I saw this about a month ago (if not longer), but since there were half a dozen people calling me an > imbecile who hadn't really yet read the code I didn't want to inflame them more by fixing that with > "a hack". (actually a simple fix). > > A simple fix is to clamp callwheel size to the previous result of a maxusers of 384 and call it a day. > > However the simplicity of that approach would probably inflame too many feelings so I am unsure as > how to proceed. > > Any ideas? I noticed the callwheel dependency as well and asked mav@ about it in a short email exchange. He said it has only little use and goes away with the calloutng import. While that is outstanding we need to clamp it to a sane value. However I don't know what a sane value would be and why its size is directly derived from maxproc and maxfiles. If there can be one callout per process and open file descriptor in the system, then it probably has to be so big. If it can deal with 'collisions' in the wheel it can be much smaller. -- Andre From owner-freebsd-arch@FreeBSD.ORG Mon Jan 14 15:51:40 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1CD24B3F; Mon, 14 Jan 2013 15:51:40 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com [209.85.214.43]) by mx1.freebsd.org (Postfix) with ESMTP id 8B50D112; Mon, 14 Jan 2013 15:51:38 +0000 (UTC) Received: by mail-bk0-f43.google.com with SMTP id jf20so2095752bkc.30 for ; Mon, 14 Jan 2013 07:51:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=8dWv/Q4R3Sd3oz0GATFy77UA0UR87LtTzChQ6qO+U9c=; b=yrxy1X5hRA3NKHii/S4oUGd8mq13rpSA5Xvp3iZhkx9254Sufov+dzvqaUQyJGlqXA i4JZfAQLlywYI9vPAZnvbUUpHzbMmTsNsHYFPCI7KNfSpf9ke0waBv8r8FWjUETwYy1Q /r+UWMYUlwnYjlA2zdiSp/xGWPLRjunev11I3tE+H6EG3Ef4IzVlJOUAtyIRQ+Gp2seo nNOA1k391n+L4n9RnS+KlfpiumEHqmxELRe4SRRgzexkeWwU4b0WetW0WqBh6Rynd4Dc d4Kbks4+K0PuXHhVjcMetazuQMYd0vPP2CpLWZgLagb0LQZeoNzbI5qT8MOVxVyc/XNd 5f8A== X-Received: by 10.204.147.143 with SMTP id l15mr40422061bkv.28.1358178691948; Mon, 14 Jan 2013 07:51:31 -0800 (PST) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id m20sm10183415bkw.4.2013.01.14.07.51.29 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 14 Jan 2013 07:51:31 -0800 (PST) Sender: Alexander Motin Message-ID: <50F4297F.8050708@FreeBSD.org> Date: Mon, 14 Jan 2013 17:51:27 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Andre Oppermann Subject: Re: svn commit: r243631 - in head/sys: kern sys References: <201211272119.qARLJxXV061083@svn.freebsd.org> <50C1BC90.90106@freebsd.org> <50C25A27.4060007@bluezbox.com> <50C26331.6030504@freebsd.org> <50C26AE9.4020600@bluezbox.com> <50C3A3D3.9000804@freebsd.org> <50C3AF72.4010902@rice.edu> <330405A1-312A-45A5-BB86-4969478D8BBD@bluezbox.com> <50D03E83.8060908@rice.edu> <50DD081E.8000409@bluezbox.com> <50EB1841.5030006@bluezbox.com> <50EB22D2.6090103@rice.edu> <50EB415F.8020405@freebsd.org> <50F04FE5.7010406@rice.edu> <50F1BD69.4060104@mu.org> <50F2F79C.7040109@mu.org> <50F41F8C.5030900@freebsd.org> In-Reply-To: <50F41F8C.5030900@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 14 Jan 2013 16:11:17 +0000 Cc: Adrian Chadd , src-committers@freebsd.org, Alan Cox , "Jayachandran C." , svn-src-all@freebsd.org, Alfred Perlstein , Oleksandr Tymoshenko , freebsd-arch@freebsd.org, svn-src-head@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 15:51:40 -0000 On 14.01.2013 17:09, Andre Oppermann wrote: > On 13.01.2013 19:06, Alfred Perlstein wrote: >> On 1/12/13 10:32 PM, Adrian Chadd wrote: >>> On 12 January 2013 11:45, Alfred Perlstein wrote: >>> >>>> I'm not sure if regressing to the waterfall method of development is >>>> a good >>>> idea at this point. >>>> >>>> I see a light at the end of the tunnel and we to continue to just >>>> handle >>>> these minor corner cases as we progress. >>>> >>>> If we move to a model where a minor bug is grounds to completely remove >>>> helpful code then nothing will ever get done. >>>> >>> Allocating 512MB worth of callwheels on a 16GB MIPS machine is a >>> little silly, don't you think? >>> >>> That suggests to me that the extent of which maxfiles/maxusers/etc >>> percolates the codebase wasn't totally understood by those who wish to >>> change it. >>> >>> I'd rather see some more investigative work into outlining things that >>> need fixing and start fixing those, rather than "just change stuff and >>> fix whatever issues creep up." >>> >>> I kinda hope we all understand what we're working on in the kernel a >>> little better than that. >> >> Cool! I'm glad people are now aware of the callwheel allocation >> being insane with large maxusers. >> >> I saw this about a month ago (if not longer), but since there were >> half a dozen people calling me an >> imbecile who hadn't really yet read the code I didn't want to inflame >> them more by fixing that with >> "a hack". (actually a simple fix). >> >> A simple fix is to clamp callwheel size to the previous result of a >> maxusers of 384 and call it a day. >> >> However the simplicity of that approach would probably inflame too >> many feelings so I am unsure as >> how to proceed. >> >> Any ideas? > > I noticed the callwheel dependency as well and asked mav@ about it > in a short email exchange. He said it has only little use and goes > away with the calloutng import. While that is outstanding we need > to clamp it to a sane value. > > However I don't know what a sane value would be and why its size is > directly derived from maxproc and maxfiles. If there can be one > callout per process and open file descriptor in the system, then > it probably has to be so big. If it can deal with 'collisions' > in the wheel it can be much smaller. As I've actually written, there are two different things: ncallout -- number of preallocated callout structures for purposes of timeout() calls. That is a legacy API that is probably not very much used now, so that value don't need to be too big. But that allocation is static and if it will ever be exhausted system will panic. That is why it was set quite high. The right way now would be to analyze where that API is still used and estimate the really required number. callwheelsize -- number of slots in the callwheel. That is purely optimizational value. If set too low, it will just increase number of hash collisions without effects other then some slowdown. Optimal value here does depend on number of callouts in system, but not only. Since array index there is not really a hash, it is practically useless to set array size it higher then median callout interval divided by hz (or by 1ms in calloutng). The problem is to estimate that median value, that completely depends on workload. Each one ncallout cost 32-52 bytes, while one callwheelsize only 8-16 and could probably be reduced to 4-8 by replacing TAILQ with LIST. So that is ncallout and respective timeout() API what should be managed in first order. -- Alexander Motin From owner-freebsd-arch@FreeBSD.ORG Mon Jan 14 16:16:13 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D8DF95E6; Mon, 14 Jan 2013 16:16:13 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id B1E43254; Mon, 14 Jan 2013 16:16:13 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (unknown [64.25.27.130]) by elvis.mu.org (Postfix) with ESMTPSA id 0FA2A1A3C24; Mon, 14 Jan 2013 08:16:11 -0800 (PST) Message-ID: <50F42F4B.303@mu.org> Date: Mon, 14 Jan 2013 11:16:11 -0500 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Andre Oppermann Subject: Re: svn commit: r243631 - in head/sys: kern sys References: <201211272119.qARLJxXV061083@svn.freebsd.org> <50C1BC90.90106@freebsd.org> <50C25A27.4060007@bluezbox.com> <50C26331.6030504@freebsd.org> <50C26AE9.4020600@bluezbox.com> <50C3A3D3.9000804@freebsd.org> <50C3AF72.4010902@rice.edu> <330405A1-312A-45A5-BB86-4969478D8BBD@bluezbox.com> <50D03E83.8060908@rice.edu> <50DD081E.8000409@bluezbox.com> <50EB1841.5030006@bluezbox.com> <50EB22D2.6090103@rice.edu> <50EB415F.8020405@freebsd.org> <50F04FE5.7010406@rice.edu> <50F1BD69.4060104@mu.org> <50F2F79C.7040109@mu.org> <50F41F8C.5030900@freebsd.org> In-Reply-To: <50F41F8C.5030900@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , src-committers@freebsd.org, Alan Cox , "Jayachandran C." , svn-src-all@freebsd.org, Oleksandr Tymoshenko , freebsd-arch@freebsd.org, svn-src-head@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 16:16:13 -0000 On 1/14/13 10:09 AM, Andre Oppermann wrote: > On 13.01.2013 19:06, Alfred Perlstein wrote: >> On 1/12/13 10:32 PM, Adrian Chadd wrote: >>> On 12 January 2013 11:45, Alfred Perlstein wrote: >>> >>>> I'm not sure if regressing to the waterfall method of development >>>> is a good >>>> idea at this point. >>>> >>>> I see a light at the end of the tunnel and we to continue to just >>>> handle >>>> these minor corner cases as we progress. >>>> >>>> If we move to a model where a minor bug is grounds to completely >>>> remove >>>> helpful code then nothing will ever get done. >>>> >>> Allocating 512MB worth of callwheels on a 16GB MIPS machine is a >>> little silly, don't you think? >>> >>> That suggests to me that the extent of which maxfiles/maxusers/etc >>> percolates the codebase wasn't totally understood by those who wish to >>> change it. >>> >>> I'd rather see some more investigative work into outlining things that >>> need fixing and start fixing those, rather than "just change stuff and >>> fix whatever issues creep up." >>> >>> I kinda hope we all understand what we're working on in the kernel a >>> little better than that. >> >> Cool! I'm glad people are now aware of the callwheel allocation >> being insane with large maxusers. >> >> I saw this about a month ago (if not longer), but since there were >> half a dozen people calling me an >> imbecile who hadn't really yet read the code I didn't want to inflame >> them more by fixing that with >> "a hack". (actually a simple fix). >> >> A simple fix is to clamp callwheel size to the previous result of a >> maxusers of 384 and call it a day. >> >> However the simplicity of that approach would probably inflame too >> many feelings so I am unsure as >> how to proceed. >> >> Any ideas? > > I noticed the callwheel dependency as well and asked mav@ about it > in a short email exchange. He said it has only little use and goes > away with the calloutng import. While that is outstanding we need > to clamp it to a sane value. > > However I don't know what a sane value would be and why its size is > directly derived from maxproc and maxfiles. If there can be one > callout per process and open file descriptor in the system, then > it probably has to be so big. If it can deal with 'collisions' > in the wheel it can be much smaller. > If it really goes away with calloutng, then we should probably leave it be in -current. As far as clipping it when/if we push maxusers fixes in -stable (which we must do) then my impression (although maybe wrong) is that the callwheels (cc_callwheel) are just arrays of hash buckets based on what tick will be fired next MOD callwheelmask. This means that if cc_callwheel is way too small, then we will wind up with collisions, however if it's enormous then we wind up with a window that is so large it can accommodate something like hundreds of ticks into the future. Example: > Loaded symbols for /boot/kernel/profile.ko > #0 sched_switch (td=0xffffffff81373e40, newtd=0xfffffe001aab5960, > flags=) at ../../../kern/sched_ule.c:1954 > 1954 cpuid = PCPU_GET(cpuid); > (kgdb) p callwheelsize > $1 = 2097152 > Current language: auto; currently minimal > (kgdb) # .(16:06:31)(root@dan) > /usr/home/alfred # sysctl -a | grep hz > kern.clockrate: { hz = 1000, tick = 1000, profhz = 8128, stathz = 127 } > kern.dcons.poll_hz: 25 > kern.hz: 1000 > debug.psm.hz: 20 > .(16:06:37)(root@dan) > /usr/home/alfred # 2097152 > .(16:06:40)(root@dan) > /usr/home/alfred # bc > 2097152 / 1000 > 2097 > ^D# .(16:06:56)(root@dan) > /usr/home/alfred # sysctl kern.maxusers > kern.maxusers: 3406 So basically on this box there are enough callwheel slots for something like 2097 seconds, or 34 minutes into the future. I would assume that a machine that was capped at 384 maxusers would wind up with something that could handle callouts up to ~3 minutes in the future without wraparound and collisions. As far as the ncallout, that is for timeout(9) support. At a glance I'm not aware of any users of timeout(9) that are not "per device" so there's unlikely to be a need for a timeout(9) supporting pre-allocated timeout per prorcess/file, more likely something like N-devices*4, which is fine at something way lower than the max allocated at 384 maxusers from before all the changes we have made. I could be wrong.. but I still believe that it would be quite the system that would need more than callout=get_callout_from_maxusers(min(maxusers, 384)); Functions calling this function: timeout Functions calling this function: timeout File Function Line 0 si.c si_start 1439 pp->lstart_ch = timeout(si_lstart, (caddr_t)pp, time); 1 sio.c siobusycheck 1269 timeout(siobusycheck, com, hz / 100); 2 sio.c siopoll 1744 timeout(siobusycheck, com, hz / 100); 3 sio.c siosettimeout 2203 sio_timeout_handle = timeout(comwakeup, (void *)NULL, 4 sio.c comwakeup 2220 sio_timeout_handle = timeout(comwakeup, (void *)NULL, sio_timeout); 5 syscons.c scrn_timer 1834 timeout(scrn_timer, sc, hz / 10); 6 syscons.c scrn_timer 1884 timeout(scrn_timer, sc, hz / 10); 7 syscons.c scrn_timer 1902 timeout(scrn_timer, sc, hz / 25); 8 syscons.c blink_screen 3847 timeout(blink_screen, scp, hz / 10); 9 trm.c trm_ExecuteSRB 478 ccb->ccb_h.timeout_ch = timeout(trmtimeout, (caddr_t)srb, (ccb->ccb_h.timeout * hz) / 1000); a tws_cam.c tws_execute_scsi 782 ccb_h->timeout_ch = timeout(tws_timeout, req, (ccb_h->timeout * hz)/1000); b tws_cam.c tws_send_scsi_cmd 820 req->thandle = timeout(tws_timeout, req, (TWS_IO_TIMEOUT * hz)); c tws_cam.c tws_set_param 867 req->thandle = timeout(tws_timeout, req, (TWS_IOCTL_TIMEOUT * hz)); d tws_services.c tws_print_stats 398 timeout(tws_print_stats, sc, 300*hz); e if_wl.c wlstart 1022 sc->watchdog_ch = timeout(wlwatchdog, sc, 10); f spic.c spictimeout 429 sc->sc_timeout_ch = timeout(spictimeout, sc, spic_pollrate); g spic.c spictimeout 442 sc->sc_timeout_ch = timeout(spictimeout, sc, spic_pollrate); h spic.c spicopen 459 timeout(spictimeout, sc, spic_pollrate); i kern_cons.c sysbeep 624 timeout(sysbeepstop, (void *)NULL, period); j kern_fail.c fail_point_sleep 133 timeout(fp->fp_sleep_fn, fp->fp_sleep_arg, timo); k aarp.c aarptimer 128 aarptimer_ch = timeout(aarptimer, NULL, AARPT_AGE * hz); l aarp.c aarptnew 580 aarptimer_ch = timeout(aarptimer, (caddr_t)0, hz); m ng_btsocket_l2cap.c ng_btsocket_l2cap_timeout 2663 pcb->timo = timeout(ng_btsocket_l2cap_process_timeout, pcb, n ng_btsocket_rfcomm.c ng_btsocket_rfcomm_timeou 3449 pcb->timo = timeout(ng_btsocket_rfcomm_process_timeout, pcb, o ng_fec.c ng_fec_init 642 priv->fec_ch = timeout(ng_fec_tick, priv, hz); p ng_fec.c ng_fec_tick 717 priv->fec_ch = timeout(ng_fec_tick, priv, hz); q key.c key_timehandler 4551 (void )timeout((void *)key_timehandler, (void *)0, hz); r key.c key_init 7776 timeout((void *)key_timehandler, (void *)0, hz); s ncp_subr.c ncp_init 107 ncp_timer_handle = timeout(ncp_timer, NULL, NCP_TIMER_TICK); t fdc.c fd_turnon 1186 timeout(fd_motor_on, fd, hz); u fdc.c fdstate 1786 fd->toffhandle = timeout(fd_turnoff, fd, 4 * hz); v fdc.c fdstate 1877 timeout(fd_pseudointr, fdc, hz / 16); w fdc.c fdstate 2092 fd->tohandle = timeout(fd_iotimeout, fdc, hz); x fdc.c fdstate 2101 fd->tohandle = timeout(fd_iotimeout, fdc, hz); y fdc.c fdstate 2218 timeout(fd_pseudointr, fdc, hz / 8); * Lines 71-106 of 115, 10 more - press the space bar to display more * Functions calling this function: timeout File Function Line 0 olpt.c lptopen 421 timeout (lptout, (caddr_t)sc, 1 olpt.c lptout 440 timeout (lptout, (caddr_t)sc, sc->sc_backoff); 2 pckbd.c pckbd_timeout 260 timeout(pckbd_timeout, arg, hz/10); 3 sio.c sioattach 2012 timeout(siobusycheck, com, hz / 100); 4 sio.c sioattach 2696 timeout(siobusycheck, com, hz / 100); 5 sio.c sioattach 3330 sio_timeout_handle = timeout(comwakeup, (void *)NULL, 6 sio.c sioattach 3347 sio_timeout_handle = timeout(comwakeup, (void *)NULL, sio_timeout); 7 sio.c sioattach 3933 timeout(pc98_check_msr, (caddr_t)dev, 8 sio.c sioattach 3951 timeout(pc98_check_msr, (caddr_t)dev, 9 ncr.c ncr_timeout 5171 timeout (ncr_timeout, (caddr_t) np, step ? step : 1); * Press the space bar to display the first lines again * -Alfred From owner-freebsd-arch@FreeBSD.ORG Mon Jan 14 16:22:03 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DA8FCB25; Mon, 14 Jan 2013 16:22:03 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id B95D72BB; Mon, 14 Jan 2013 16:22:03 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 177FCB95B; Mon, 14 Jan 2013 11:22:03 -0500 (EST) From: John Baldwin To: freebsd-arch@freebsd.org, toolchain@freebsd.org Subject: Re: Fast sigblock (AKA rtld speedup) Date: Mon, 14 Jan 2013 11:06:07 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <20130107182235.GA65279@kib.kiev.ua> <20130112053147.GH2561@kib.kiev.ua> <20130112162547.GA54954@stack.nl> In-Reply-To: <20130112162547.GA54954@stack.nl> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201301141106.07976.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 14 Jan 2013 11:22:03 -0500 (EST) Cc: Konstantin Belousov , Jilles Tjoelker X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 16:22:03 -0000 On Saturday, January 12, 2013 11:25:47 am Jilles Tjoelker wrote: > With that, I think fast sigblock is too much code and complication for a > niche case. It does seem a bit complicated to me as well. > Most of the extra atomics in multi-threaded applications are conditional > on __isthreaded (or can be made so); therefore, performance loss from > linking in libthr should be negligible in most cases. Sadly, this is not true. libstdc++ turns on locking if you merely link against libthr, not based on testing __isthreaded. (It does this by testing to see if pthread_once() works during startup, and we have to intentionally sabotage the pthread_once() in libc to fail for this to work which annoys me for an entirely different set of reasons.) At work we go to great lengths to avoid linking in libthr for exactly this reason (e.g. we have a custom port of boost that builds a separate set of boost libraries that are explicitly not linked against libthr), and we also care about exception performance (one of my co-workers submitted the PR about exception performance). -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Mon Jan 14 16:22:05 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 73125B26; Mon, 14 Jan 2013 16:22:05 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 51EFE2BD; Mon, 14 Jan 2013 16:22:05 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B8080B963; Mon, 14 Jan 2013 11:22:04 -0500 (EST) From: John Baldwin To: freebsd-arch@freebsd.org Subject: Re: how long to keep support for gcc on x86? Date: Mon, 14 Jan 2013 11:10:44 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <20130112233147.GK1410@funkthat.com> <20130113132402.GR2561@kib.kiev.ua> In-Reply-To: <20130113132402.GR2561@kib.kiev.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201301141110.44165.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 14 Jan 2013 11:22:04 -0500 (EST) Cc: Konstantin Belousov , Adrian Chadd X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 16:22:05 -0000 On Sunday, January 13, 2013 8:24:02 am Konstantin Belousov wrote: > On Sun, Jan 13, 2013 at 12:09:09AM -0800, Peter Wemm wrote: > > On Sat, Jan 12, 2013 at 11:44 PM, Adrian Chadd wrote: > > > > > Thus I think adding clang-only code to the system right now is very, > > > very premature. There still seem to be reasons to run systems on GCC > > > instead of clang. > > > > I don't have a problem with it so long as the system isn't *broken* if > > you're not using clang. ie: if the status-quo is maintained for gcc > > systems and g-faster bits are enabled with clang. It's fine to > > provide incentives to try clang, but it is not ok to regress the gcc > > case. > Absolutely agree. > > Please note that in the AES-NI case, gcc 'support' is only partially > gcc issue, if gcc at all. Our 2.17 gas does not know about AES-NI > mnemonics and cannot assemble them. It is not but so hard to add new instructions to binutils. I did it recently for the xsave stuff as well the instructions needed by bhyve. How many instructions are you talking about (and which ones)? -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Mon Jan 14 16:50:12 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 46527811; Mon, 14 Jan 2013 16:50:12 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 331EA648; Mon, 14 Jan 2013 16:50:12 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (unknown [64.25.27.130]) by elvis.mu.org (Postfix) with ESMTPSA id 6692E1A3CDA; Mon, 14 Jan 2013 08:50:06 -0800 (PST) Message-ID: <50F4373B.5080203@mu.org> Date: Mon, 14 Jan 2013 11:50:03 -0500 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: John Baldwin Subject: Re: Fast sigblock (AKA rtld speedup) References: <20130107182235.GA65279@kib.kiev.ua> <20130112053147.GH2561@kib.kiev.ua> <20130112162547.GA54954@stack.nl> <201301141106.07976.jhb@freebsd.org> In-Reply-To: <201301141106.07976.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , toolchain@freebsd.org, Jilles Tjoelker , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 16:50:12 -0000 On 1/14/13 11:06 AM, John Baldwin wrote: > On Saturday, January 12, 2013 11:25:47 am Jilles Tjoelker wrote: >> With that, I think fast sigblock is too much code and complication for a >> niche case. > It does seem a bit complicated to me as well. > >> Most of the extra atomics in multi-threaded applications are conditional >> on __isthreaded (or can be made so); therefore, performance loss from >> linking in libthr should be negligible in most cases. > Sadly, this is not true. libstdc++ turns on locking if you merely link > against libthr, not based on testing __isthreaded. (It does this by testing > to see if pthread_once() works during startup, and we have to intentionally > sabotage the pthread_once() in libc to fail for this to work which annoys me > for an entirely different set of reasons.) > > At work we go to great lengths to avoid linking in libthr for exactly this > reason (e.g. we have a custom port of boost that builds a separate set of > boost libraries that are explicitly not linked against libthr), and we also > care about exception performance (one of my co-workers submitted the PR about > exception performance). > I get frustrated when people ask me "but why are you doing that?", but I have to know... why do we/you need fast exception handling? Are you throwing a high rate of exceptions? Or is it just that your application is that sensitive to exceptions being thrown that a single slowish one has an impact? -Alfred From owner-freebsd-arch@FreeBSD.ORG Mon Jan 14 17:16:29 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D316FD56; Mon, 14 Jan 2013 17:16:29 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id A958B7A2; Mon, 14 Jan 2013 17:16:29 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (unknown [64.25.27.130]) by elvis.mu.org (Postfix) with ESMTPSA id 9B1C51A3CE3; Mon, 14 Jan 2013 09:16:28 -0800 (PST) Message-ID: <50F43D6A.9010303@mu.org> Date: Mon, 14 Jan 2013 12:16:26 -0500 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Alexander Motin Subject: Re: svn commit: r243631 - in head/sys: kern sys References: <201211272119.qARLJxXV061083@svn.freebsd.org> <50C1BC90.90106@freebsd.org> <50C25A27.4060007@bluezbox.com> <50C26331.6030504@freebsd.org> <50C26AE9.4020600@bluezbox.com> <50C3A3D3.9000804@freebsd.org> <50C3AF72.4010902@rice.edu> <330405A1-312A-45A5-BB86-4969478D8BBD@bluezbox.com> <50D03E83.8060908@rice.edu> <50DD081E.8000409@bluezbox.com> <50EB1841.5030006@bluezbox.com> <50EB22D2.6090103@rice.edu> <50EB415F.8020405@freebsd.org> <50F04FE5.7010406@rice.edu> <50F1BD69.4060104@mu.org> <50F2F79C.7040109@mu.org> <50F41F8C.5030900@freebsd.org> <50F4297F.8050708@FreeBSD.org> <50F42CD7.6020400@freebsd.org> <50F430E3.70501@FreeBSD.org> In-Reply-To: <50F430E3.70501@FreeBSD.org> Content-Type: multipart/mixed; boundary="------------050704080205010807000909" Cc: Adrian Chadd , Andre Oppermann , Alan Cox , "Jayachandran C." , Oleksandr Tymoshenko , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 17:16:29 -0000 This is a multi-part message in MIME format. --------------050704080205010807000909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit [[ moved to -arch ]] On 1/14/13 11:22 AM, Alexander Motin wrote: > On 14.01.2013 18:05, Andre Oppermann wrote: >> On 14.01.2013 16:51, Alexander Motin wrote: >>> As I've actually written, there are two different things: >>> ncallout -- number of preallocated callout structures for purposes of >>> timeout() calls. That is a legacy API that is probably not very much >>> used now, so that value don't need to be too big. But that allocation is >>> static and if it will ever be exhausted system will panic. That is why >>> it was set quite high. The right way now would be to analyze where that >>> API is still used and estimate the really required number. >> Can timeout() be emulated on top of another API so we can do away with it? > It is already emulated on top of callout_init()/callout_reset(). The > problem is that callout_init()/callout_reset() assume storage memory to > be allocated by consumer, while timeout() assumes it to be allocated by > subsystem. The only way to solve it is to rewrite remaining timeout() > consumers to use callout_init()/callout_reset() API directly. The following diff should suffice as a fine stop-gap and is no worse than what we've lived with for the past 10 years. What it does is cap the amount of callouts to a function of maxusers as if the old limit of 384 was in place. A more comprehensive fix is not needed because we are about to do away with the entire mess anyhow. I'm doing some testing with it. Let me know what you think. -Alfred --------------050704080205010807000909 Content-Type: text/plain; charset=UTF-8; x-mac-type="0"; x-mac-creator="0"; name="ncallout_max.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ncallout_max.diff" Index: subr_param.c =================================================================== --- subr_param.c (revision 245315) +++ subr_param.c (working copy) @@ -324,8 +324,11 @@ /* * XXX: Does the callout wheel have to be so big? + * + * Clip callout to result of previous function of maxusers maximum + * 384. This is still huge, but acceptable. */ - ncallout = 16 + maxproc + maxfiles; + ncallout = min(16 + maxproc + maxfiles, 18508); TUNABLE_INT_FETCH("kern.ncallout", &ncallout); /* --------------050704080205010807000909-- From owner-freebsd-arch@FreeBSD.ORG Mon Jan 14 16:05:45 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BD56810D for ; Mon, 14 Jan 2013 16:05:45 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 1F50C1AB for ; Mon, 14 Jan 2013 16:05:44 +0000 (UTC) Received: (qmail 61937 invoked from network); 14 Jan 2013 17:28:38 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 14 Jan 2013 17:28:38 -0000 Message-ID: <50F42CD7.6020400@freebsd.org> Date: Mon, 14 Jan 2013 17:05:43 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Alexander Motin Subject: Re: svn commit: r243631 - in head/sys: kern sys References: <201211272119.qARLJxXV061083@svn.freebsd.org> <50C1BC90.90106@freebsd.org> <50C25A27.4060007@bluezbox.com> <50C26331.6030504@freebsd.org> <50C26AE9.4020600@bluezbox.com> <50C3A3D3.9000804@freebsd.org> <50C3AF72.4010902@rice.edu> <330405A1-312A-45A5-BB86-4969478D8BBD@bluezbox.com> <50D03E83.8060908@rice.edu> <50DD081E.8000409@bluezbox.com> <50EB1841.5030006@bluezbox.com> <50EB22D2.6090103@rice.edu> <50EB415F.8020405@freebsd.org> <50F04FE5.7010406@rice.edu> <50F1BD69.4060104@mu.org> <50F2F79C.7040109@mu.org> <50F41F8C.5030900@freebsd.org> <50F4297F.8050708@FreeBSD.org> In-Reply-To: <50F4297F.8050708@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 14 Jan 2013 17:30:54 +0000 Cc: Adrian Chadd , src-committers@freebsd.org, Alan Cox , "Jayachandran C." , svn-src-all@freebsd.org, Alfred Perlstein , Oleksandr Tymoshenko , freebsd-arch@freebsd.org, svn-src-head@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 16:05:45 -0000 On 14.01.2013 16:51, Alexander Motin wrote: > On 14.01.2013 17:09, Andre Oppermann wrote: >> On 13.01.2013 19:06, Alfred Perlstein wrote: >>> On 1/12/13 10:32 PM, Adrian Chadd wrote: >>>> On 12 January 2013 11:45, Alfred Perlstein wrote: >>>> >>>>> I'm not sure if regressing to the waterfall method of development is >>>>> a good >>>>> idea at this point. >>>>> >>>>> I see a light at the end of the tunnel and we to continue to just >>>>> handle >>>>> these minor corner cases as we progress. >>>>> >>>>> If we move to a model where a minor bug is grounds to completely remove >>>>> helpful code then nothing will ever get done. >>>>> >>>> Allocating 512MB worth of callwheels on a 16GB MIPS machine is a >>>> little silly, don't you think? >>>> >>>> That suggests to me that the extent of which maxfiles/maxusers/etc >>>> percolates the codebase wasn't totally understood by those who wish to >>>> change it. >>>> >>>> I'd rather see some more investigative work into outlining things that >>>> need fixing and start fixing those, rather than "just change stuff and >>>> fix whatever issues creep up." >>>> >>>> I kinda hope we all understand what we're working on in the kernel a >>>> little better than that. >>> >>> Cool! I'm glad people are now aware of the callwheel allocation >>> being insane with large maxusers. >>> >>> I saw this about a month ago (if not longer), but since there were >>> half a dozen people calling me an >>> imbecile who hadn't really yet read the code I didn't want to inflame >>> them more by fixing that with >>> "a hack". (actually a simple fix). >>> >>> A simple fix is to clamp callwheel size to the previous result of a >>> maxusers of 384 and call it a day. >>> >>> However the simplicity of that approach would probably inflame too >>> many feelings so I am unsure as >>> how to proceed. >>> >>> Any ideas? >> >> I noticed the callwheel dependency as well and asked mav@ about it >> in a short email exchange. He said it has only little use and goes >> away with the calloutng import. While that is outstanding we need >> to clamp it to a sane value. >> >> However I don't know what a sane value would be and why its size is >> directly derived from maxproc and maxfiles. If there can be one >> callout per process and open file descriptor in the system, then >> it probably has to be so big. If it can deal with 'collisions' >> in the wheel it can be much smaller. > > As I've actually written, there are two different things: > ncallout -- number of preallocated callout structures for purposes of > timeout() calls. That is a legacy API that is probably not very much > used now, so that value don't need to be too big. But that allocation is > static and if it will ever be exhausted system will panic. That is why > it was set quite high. The right way now would be to analyze where that > API is still used and estimate the really required number. Can timeout() be emulated on top of another API so we can do away with it? > callwheelsize -- number of slots in the callwheel. That is purely > optimizational value. If set too low, it will just increase number of > hash collisions without effects other then some slowdown. Optimal value > here does depend on number of callouts in system, but not only. Since > array index there is not really a hash, it is practically useless to set > array size it higher then median callout interval divided by hz (or by > 1ms in calloutng). The problem is to estimate that median value, that > completely depends on workload. OK. So for example a large number of TCP connection would use up a large number of slots in the callwheel. I'll try to come up with a reasonable sane scaling value. > Each one ncallout cost 32-52 bytes, while one callwheelsize only 8-16 > and could probably be reduced to 4-8 by replacing TAILQ with LIST. So > that is ncallout and respective timeout() API what should be managed in > first order. I'll give it a try. -- Andre From owner-freebsd-arch@FreeBSD.ORG Mon Jan 14 17:43:52 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 80D80404; Mon, 14 Jan 2013 17:43:52 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 588C78D7; Mon, 14 Jan 2013 17:43:52 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id AE32EB948; Mon, 14 Jan 2013 12:43:51 -0500 (EST) From: John Baldwin To: Alfred Perlstein Subject: Re: Fast sigblock (AKA rtld speedup) Date: Mon, 14 Jan 2013 12:43:40 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <20130107182235.GA65279@kib.kiev.ua> <201301141106.07976.jhb@freebsd.org> <50F4373B.5080203@mu.org> In-Reply-To: <50F4373B.5080203@mu.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201301141243.40130.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 14 Jan 2013 12:43:51 -0500 (EST) Cc: Konstantin Belousov , toolchain@freebsd.org, Jilles Tjoelker , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 17:43:52 -0000 On Monday, January 14, 2013 11:50:03 am Alfred Perlstein wrote: > On 1/14/13 11:06 AM, John Baldwin wrote: > > On Saturday, January 12, 2013 11:25:47 am Jilles Tjoelker wrote: > >> With that, I think fast sigblock is too much code and complication for a > >> niche case. > > It does seem a bit complicated to me as well. > > > >> Most of the extra atomics in multi-threaded applications are conditional > >> on __isthreaded (or can be made so); therefore, performance loss from > >> linking in libthr should be negligible in most cases. > > Sadly, this is not true. libstdc++ turns on locking if you merely link > > against libthr, not based on testing __isthreaded. (It does this by testing > > to see if pthread_once() works during startup, and we have to intentionally > > sabotage the pthread_once() in libc to fail for this to work which annoys me > > for an entirely different set of reasons.) > > > > At work we go to great lengths to avoid linking in libthr for exactly this > > reason (e.g. we have a custom port of boost that builds a separate set of > > boost libraries that are explicitly not linked against libthr), and we also > > care about exception performance (one of my co-workers submitted the PR about > > exception performance). > > > I get frustrated when people ask me "but why are you doing that?", but I > have to know... why do we/you need fast exception handling? > > Are you throwing a high rate of exceptions? Or is it just that your > application is that sensitive to exceptions being thrown that a single > slowish one has an impact? More that it is sensitive. Not all exceptions result in an immediate call to exit(). -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Mon Jan 14 17:47:19 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F3D556A6; Mon, 14 Jan 2013 17:47:18 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (unknown [IPv6:2001:610:1108:5012::107]) by mx1.freebsd.org (Postfix) with ESMTP id BB73090C; Mon, 14 Jan 2013 17:47:18 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 5F321120400; Mon, 14 Jan 2013 18:47:03 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id 4760E2848C; Mon, 14 Jan 2013 18:47:03 +0100 (CET) Date: Mon, 14 Jan 2013 18:47:03 +0100 From: Jilles Tjoelker To: John Baldwin Subject: Re: Fast sigblock (AKA rtld speedup) Message-ID: <20130114174703.GB88220@stack.nl> References: <20130107182235.GA65279@kib.kiev.ua> <20130112053147.GH2561@kib.kiev.ua> <20130112162547.GA54954@stack.nl> <201301141106.07976.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201301141106.07976.jhb@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Konstantin Belousov , toolchain@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 17:47:19 -0000 On Mon, Jan 14, 2013 at 11:06:07AM -0500, John Baldwin wrote: > On Saturday, January 12, 2013 11:25:47 am Jilles Tjoelker wrote: > > With that, I think fast sigblock is too much code and complication > > for a niche case. > It does seem a bit complicated to me as well. > > Most of the extra atomics in multi-threaded applications are > > conditional on __isthreaded (or can be made so); therefore, > > performance loss from linking in libthr should be negligible in most > > cases. > Sadly, this is not true. libstdc++ turns on locking if you merely > link against libthr, not based on testing __isthreaded. (It does this > by testing to see if pthread_once() works during startup, and we have > to intentionally sabotage the pthread_once() in libc to fail for this > to work which annoys me for an entirely different set of reasons.) > At work we go to great lengths to avoid linking in libthr for exactly > this reason (e.g. we have a custom port of boost that builds a > separate set of boost libraries that are explicitly not linked against > libthr), and we also care about exception performance (one of my > co-workers submitted the PR about exception performance). The code which does that check is actually under contrib/gcc. Problem is, they designed __gthread_active_p() to distinguish threaded and unthreaded programming environments -- it must be known in advance and cannot be changed later. The code for the unthreaded environment then takes advantage of this by not even allocating memory for mutexes in some cases. So there is no way around __gthread_active_p() returning true if libthr is linked in. The __isthreaded check will have to be in libthr or in contrib/gcc/gthr-posix.c and it will not do much more than avoiding atomics. This __gthread_active_p() thing is another barrier to bringing in a threaded plugin in an unthreaded application. Ports people spend a fair amount of time adding -pthread flags to things (such as perl) to work around this. -- Jilles Tjoelker From owner-freebsd-arch@FreeBSD.ORG Mon Jan 14 16:17:56 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 54EA78AC; Mon, 14 Jan 2013 16:17:56 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 2C37627D; Mon, 14 Jan 2013 16:17:55 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (unknown [64.25.27.130]) by elvis.mu.org (Postfix) with ESMTPSA id F18111A3C1D; Mon, 14 Jan 2013 08:17:53 -0800 (PST) Message-ID: <50F42FB1.6020401@mu.org> Date: Mon, 14 Jan 2013 11:17:53 -0500 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Andre Oppermann Subject: Re: svn commit: r243631 - in head/sys: kern sys References: <201211272119.qARLJxXV061083@svn.freebsd.org> <50C1BC90.90106@freebsd.org> <50C25A27.4060007@bluezbox.com> <50C26331.6030504@freebsd.org> <50C26AE9.4020600@bluezbox.com> <50C3A3D3.9000804@freebsd.org> <50C3AF72.4010902@rice.edu> <330405A1-312A-45A5-BB86-4969478D8BBD@bluezbox.com> <50D03E83.8060908@rice.edu> <50DD081E.8000409@bluezbox.com> <50EB1841.5030006@bluezbox.com> <50EB22D2.6090103@rice.edu> <50EB415F.8020405@freebsd.org> <50F04FE5.7010406@rice.edu> <50F1BD69.4060104@mu.org> <50F2F79C.7040109@mu.org> <50F41F8C.5030900@freebsd.org> <50F4297F.8050708@FreeBSD.org> <50F42CD7.6020400@freebsd.org> In-Reply-To: <50F42CD7.6020400@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 14 Jan 2013 18:14:40 +0000 Cc: Adrian Chadd , src-committers@freebsd.org, Alan Cox , "Jayachandran C." , Alexander Motin , Oleksandr Tymoshenko , freebsd-arch@freebsd.org, svn-src-head@freebsd.org, svn-src-all@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 16:17:56 -0000 On 1/14/13 11:05 AM, Andre Oppermann wrote: > > Can timeout() be emulated on top of another API so we can do away with > it? yes, this is what callout(9) is for. there are a few consumers left (see the email I just sent out). those consumers would just have to allocate their own callout handle/struct and pass that to callout instead of using timeout(9). -Alfred From owner-freebsd-arch@FreeBSD.ORG Mon Jan 14 16:23:12 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3779ECAE; Mon, 14 Jan 2013 16:23:12 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bk0-f41.google.com (mail-bk0-f41.google.com [209.85.214.41]) by mx1.freebsd.org (Postfix) with ESMTP id AB42D2D9; Mon, 14 Jan 2013 16:23:10 +0000 (UTC) Received: by mail-bk0-f41.google.com with SMTP id jg9so2111134bkc.0 for ; Mon, 14 Jan 2013 08:23:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=MJwK5QiJyaS9fWNMo/yaZFKa7uX/AO53ObUmDIIqHjw=; b=o5YdDbyo1DzArLT9o9PtYVdpCS+nZf8T4NlsRxoj1HKLt/dStMr0R9eiFJHplK0Uh4 a3rYEGMfBqYsagPGJaEizOAWvm36w86dVWXoXeUkbT1v5mvFOsBH3mL03ohvv9qwojyG NmquN4JKxoPuMNjy1c+fkX3pKzDGOC7iKv1vqviTtWSwZ9pl5xEum3SaD+ljKO8RtNkg uufj1s+94QEAKrKf9UTajaMuDGsXXvWRDdfjIE5Pk57GtCTSnnDlpI76xA/mfBYhbeet U/djTpAIBEsm48M+ymkL03gaYaZggwM8KpxEu0m0B10pqWNrHwfy97e9na5ukQEAF8ep UjrQ== X-Received: by 10.204.3.206 with SMTP id 14mr39244118bko.120.1358180583687; Mon, 14 Jan 2013 08:23:03 -0800 (PST) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id e22sm10318424bke.14.2013.01.14.08.23.01 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 14 Jan 2013 08:23:02 -0800 (PST) Sender: Alexander Motin Message-ID: <50F430E3.70501@FreeBSD.org> Date: Mon, 14 Jan 2013 18:22:59 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Andre Oppermann Subject: Re: svn commit: r243631 - in head/sys: kern sys References: <201211272119.qARLJxXV061083@svn.freebsd.org> <50C1BC90.90106@freebsd.org> <50C25A27.4060007@bluezbox.com> <50C26331.6030504@freebsd.org> <50C26AE9.4020600@bluezbox.com> <50C3A3D3.9000804@freebsd.org> <50C3AF72.4010902@rice.edu> <330405A1-312A-45A5-BB86-4969478D8BBD@bluezbox.com> <50D03E83.8060908@rice.edu> <50DD081E.8000409@bluezbox.com> <50EB1841.5030006@bluezbox.com> <50EB22D2.6090103@rice.edu> <50EB415F.8020405@freebsd.org> <50F04FE5.7010406@rice.edu> <50F1BD69.4060104@mu.org> <50F2F79C.7040109@mu.org> <50F41F8C.5030900@freebsd.org> <50F4297F.8050708@FreeBSD.org> <50F42CD7.6020400@freebsd.org> In-Reply-To: <50F42CD7.6020400@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 14 Jan 2013 18:15:09 +0000 Cc: Adrian Chadd , src-committers@freebsd.org, Alan Cox , "Jayachandran C." , svn-src-all@freebsd.org, Alfred Perlstein , Oleksandr Tymoshenko , freebsd-arch@freebsd.org, svn-src-head@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 16:23:12 -0000 On 14.01.2013 18:05, Andre Oppermann wrote: > On 14.01.2013 16:51, Alexander Motin wrote: >> As I've actually written, there are two different things: >> ncallout -- number of preallocated callout structures for purposes of >> timeout() calls. That is a legacy API that is probably not very much >> used now, so that value don't need to be too big. But that allocation is >> static and if it will ever be exhausted system will panic. That is why >> it was set quite high. The right way now would be to analyze where that >> API is still used and estimate the really required number. > > Can timeout() be emulated on top of another API so we can do away with it? It is already emulated on top of callout_init()/callout_reset(). The problem is that callout_init()/callout_reset() assume storage memory to be allocated by consumer, while timeout() assumes it to be allocated by subsystem. The only way to solve it is to rewrite remaining timeout() consumers to use callout_init()/callout_reset() API directly. >> callwheelsize -- number of slots in the callwheel. That is purely >> optimizational value. If set too low, it will just increase number of >> hash collisions without effects other then some slowdown. Optimal value >> here does depend on number of callouts in system, but not only. Since >> array index there is not really a hash, it is practically useless to set >> array size it higher then median callout interval divided by hz (or by >> 1ms in calloutng). The problem is to estimate that median value, that >> completely depends on workload. > > OK. So for example a large number of TCP connection would use up a > large number of slots in the callwheel. I'll try to come up with a > reasonable sane scaling value. Yes, it _may_ use, but that also depends on time intervals. If most of these TCP timeouts will be few seconds long for ACK timeout, there will be no any performance difference between having callwheelsize of 100*hz and 10000*hz. Same time, if periods are measured in hours, like for keep-alives, increasing callwheelsize may be effective. >> Each one ncallout cost 32-52 bytes, while one callwheelsize only 8-16 >> and could probably be reduced to 4-8 by replacing TAILQ with LIST. So >> that is ncallout and respective timeout() API what should be managed in >> first order. > > I'll give it a try. Thanks. -- Alexander Motin From owner-freebsd-arch@FreeBSD.ORG Mon Jan 14 18:24:14 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0730C6BC; Mon, 14 Jan 2013 18:24:14 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id D0645B0C; Mon, 14 Jan 2013 18:24:13 +0000 (UTC) Received: from [192.168.0.2] (cpc10-cmbg15-2-0-cust123.5-4.cable.virginmedia.com [86.30.246.124]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r0EIOATH014273 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Mon, 14 Jan 2013 18:24:12 GMT (envelope-from theraven@FreeBSD.org) Subject: Re: Fast sigblock (AKA rtld speedup) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_70750EDA-D886-486C-9220-8B45D4AB7DD4"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: David Chisnall In-Reply-To: <20130114174703.GB88220@stack.nl> Date: Mon, 14 Jan 2013 18:24:04 +0000 Message-Id: References: <20130107182235.GA65279@kib.kiev.ua> <20130112053147.GH2561@kib.kiev.ua> <20130112162547.GA54954@stack.nl> <201301141106.07976.jhb@freebsd.org> <20130114174703.GB88220@stack.nl> To: Jilles Tjoelker X-Mailer: Apple Mail (2.1278) Cc: toolchain@FreeBSD.org, freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 18:24:14 -0000 --Apple-Mail=_70750EDA-D886-486C-9220-8B45D4AB7DD4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 14 Jan 2013, at 17:47, Jilles Tjoelker wrote: > The code which does that check is actually under contrib/gcc. Problem > is, they designed __gthread_active_p() to distinguish threaded and > unthreaded programming environments -- it must be known in advance and > cannot be changed later. The code for the unthreaded environment then > takes advantage of this by not even allocating memory for mutexes in > some cases. It's worth taking a step back and asking why this code exists at all, = and the main reason is that acquiring a mutex used to be really = expensive. It still is on some fruit-flavoured operating systems, but = elsewhere it's a single atomic operation in the uncontended case, and in = that case the cache line will already be exclusively owned by the = calling core in single-threaded code. =20 I would much rather that we followed the example of Solaris and made the = multithreaded case fast and the default than keep piling on hacks that = allow code to shave off a few clock cycles in the single-threaded case. = In particular, the popularity of multicore systems means that it is = increasingly rare for code to be both single threaded and performance = critical, so this seems like misplaced optimisation. I strongly suspect that making it possible to inline the uncontended = lock case for a pthread mutex and eliminating all of the branches on = __isthreaded would give us a net speedup in both single and = multithreaded cases. > This __gthread_active_p() thing is another barrier to bringing in a > threaded plugin in an unthreaded application. Ports people spend a = fair > amount of time adding -pthread flags to things (such as perl) to work > around this. This and the similar checks in libc cause a lot of pain, and it seems = that the correct fix is ensuring that the performance penalty for = linking libthr is so small that there is no point in avoiding it. David --Apple-Mail=_70750EDA-D886-486C-9220-8B45D4AB7DD4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) iQIcBAEBAgAGBQJQ9E1FAAoJEKx65DEEsqIdUgcP/RQ4sF0gYsuCGiWUlmiioKnE 3ZQF76ieurN7Hbmq0WNs3eAHljFzQMRPrsgqQVcbyTNPuIuSX4zIdTGLLFwBijf0 X2R0nO6e7sHTYKtCcHmXFoH7DCoQSEG88F1q7zRA1RlvOF0hXDXHEYrSCpWeBMnC 5SwcYMgsZ5eXX9a5tvsUeq2/GyDcPYEkVhq3ueZRmVxIXoaL5Eq3qZ4hReJCLo/1 AnB+/c0dAMJQE6td8gdn7+8EcbHeAblGvpRJFYaNT56WiAVbu+ZOB1l2wNRzMM3e mYsg72pfUxcqb6WWwgk4pXqPQyIMT9pHCwden2rrEpzk7qHFQUV3odVyo2SXtA44 xMWBs2d2a8fmMRCW6wrtrpb1jlPo9W4KmQWpF+4Kaq2P8DuN0ljyTRSC5PQqM4ms saFYl6OOtRFPzD/6RUddklQIi2poBhVp6hAfA2qxq0otMN1ZmkpTsRtsNZltXbpp 9fyeHpc2IsBx9uM7ND2b5FQmdXKq1Zs0sF2HC3uhH2Q7F2r39TuM/0m5eayyJosZ bWExLzQmq5gpR6guEEV4pdgye33eCL1TvVgRGOPxmpenydqEyFiflcu16bh5wRU2 DkMJGe6r9OBKqnvNOrlrtE9P16906C9XL9QwUHfnjg440/WAFW2i44zj0U+PE3Bf +GwlZRaF3NgeTX7i7nmH =ADYu -----END PGP SIGNATURE----- --Apple-Mail=_70750EDA-D886-486C-9220-8B45D4AB7DD4-- From owner-freebsd-arch@FreeBSD.ORG Mon Jan 14 18:03:20 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9BB56F55; Mon, 14 Jan 2013 18:03:20 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 749829DC; Mon, 14 Jan 2013 18:03:20 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E88E7B948; Mon, 14 Jan 2013 13:03:19 -0500 (EST) From: John Baldwin To: Alexander Motin Subject: Re: svn commit: r243631 - in head/sys: kern sys Date: Mon, 14 Jan 2013 12:55:46 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <201211272119.qARLJxXV061083@svn.freebsd.org> <50F41F8C.5030900@freebsd.org> <50F4297F.8050708@FreeBSD.org> In-Reply-To: <50F4297F.8050708@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201301141255.46994.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 14 Jan 2013 13:03:20 -0500 (EST) X-Mailman-Approved-At: Mon, 14 Jan 2013 18:35:06 +0000 Cc: Adrian Chadd , src-committers@freebsd.org, Andre Oppermann , Alan Cox , "Jayachandran C." , svn-src-all@freebsd.org, Alfred Perlstein , Oleksandr Tymoshenko , freebsd-arch@freebsd.org, svn-src-head@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 18:03:20 -0000 On Monday, January 14, 2013 10:51:27 am Alexander Motin wrote: > As I've actually written, there are two different things: > ncallout -- number of preallocated callout structures for purposes of > timeout() calls. That is a legacy API that is probably not very much > used now, so that value don't need to be too big. But that allocation is > static and if it will ever be exhausted system will panic. That is why > it was set quite high. The right way now would be to analyze where that > API is still used and estimate the really required number. FYI, I have slowly been working through the tree fixing users of timeout() to use callout_*() instead. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Mon Jan 14 18:56:50 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 76CA72E0; Mon, 14 Jan 2013 18:56:50 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id BD1D8DD4; Mon, 14 Jan 2013 18:56:49 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.5/8.14.5) with ESMTP id r0EIulEp016642; Mon, 14 Jan 2013 12:56:47 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.5/8.14.5/Submit) id r0EIukBU016641; Mon, 14 Jan 2013 12:56:46 -0600 (CST) (envelope-from brooks) Date: Mon, 14 Jan 2013 12:56:46 -0600 From: Brooks Davis To: Nathan Whitehorn , Konstantin Belousov , Ed Schouten , freebsd-toolchain@freebsd.org, freebsd-arch@freebsd.org Subject: Re: LLVM Image Activator Message-ID: <20130114185646.GB15933@lor.one-eyed-alien.net> References: <50E9BC2D.7000302@freebsd.org> <201301070936.39052.jhb@freebsd.org> <20130107172433.GX82219@kib.kiev.ua> <20130113132057.GQ2561@kib.kiev.ua> <50F2DF11.50202@freebsd.org> <20130113171304.GZ2561@kib.kiev.ua> <50F2F97B.5030306@freebsd.org> <20130113202435.GN1410@funkthat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tsOsTdHNUZQcU9Ye" Content-Disposition: inline In-Reply-To: <20130113202435.GN1410@funkthat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 18:56:50 -0000 --tsOsTdHNUZQcU9Ye Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 13, 2013 at 12:24:35PM -0800, John-Mark Gurney wrote: > Nathan Whitehorn wrote this message on Sun, Jan 13, 2013 at 10:14 -0800: > > On 01/13/13 09:13, Konstantin Belousov wrote: > > > On Sun, Jan 13, 2013 at 08:21:37AM -0800, Nathan Whitehorn wrote: > > >> On 01/13/13 05:20, Konstantin Belousov wrote: > > >>> On Sun, Jan 13, 2013 at 12:41:09PM +0100, Ed Schouten wrote: > > >>>> Hi Kostik, > > >>>> > > >>>> 2013/1/7 Konstantin Belousov : > > >>>>> I still do remember the buzz about the binary format 0xCAFEBABE, = which > > >>>>> AFAIR gained image activator support on several OSes, to be garba= ge > > >>>>> collected. > > >>>> > > >>>> Maybe it would then be a good idea then to add some kind of general > > >>>> purpose remapping imgact? Example: > > >>>> > > >>>> /etc/imgacttab: > > >>>> > > >>>> cafebabe /usr/local/bin/java > > >>>> cffaedfe /usr/local/bin/osx_emulator > > >>>> 4243c0de /usr/bin/lli > > >>>> > > >>>> That way we still give people the freedom to play around with mapp= ing > > >>>> their own executable formats, but don't need to maintain a bunch of > > >>>> imgacts. > > >>> > > >>> A generic module that could be somewhat customized at runtime to map > > >>> offset+signature into the shebang path could be a possibility indee= d. > > >>> I strongly prefer to have it as module and not enabled by default. > > >>> > > >>> Asking Nathan for writing the thing is too much, IMHO, esp. in > > >>> the response to the 50-lines hack. > > >>> > > >> > > >> I think this is a good idea, since it both prevents a profusion of > > >> similar activators and works nicely in jails and similar environment= s. I > > >> probably won't write it quickly, but it should not take more than ab= out > > >> 50 lines, so I can't imagine it will be that bad. There are some > > >> complications with this kind of design from the things in the XXX > > >> comment in imgact_llvm.c about handling argv[0] that I need to think > > >> some more about. > > > Great. I do not believe in the 50 lines, but I am happy that you want > > > to work this out. > > >=20 > > >> > > >> Why are you opposed to having it there by default? I think it's actu= ally > > >> quite important that it be there by default. Having it not "standard" > > >> would be fine, but it should at least be in GENERIC. There are minim= al > > >> security risks since it just munges begin_argv and doesn't even load= the > > >> executable and it's little enough code that there should not be any > > >> kernel bloat to speak of. If things like this aren't enabled by defa= ult, > > >> no one can depend on them being there, no one will use it, and the p= oint > > >> is entirely lost. > > > All image activators demonstrated a constant stream of security holes. > > > Even our ELF activator, and I was guilty there too. > > >=20 > > > I definitely do not fight over the inclusion of the proposed activator > > > into GENERIC, but do insist on the config option + module. > > >=20 > >=20 > > OK, that sounds like a plan then. I'll try to code up something > > configurable in the next couple weeks, unless someone else beats me to = it. >=20 > I'll point out that file already has the magic (pun intended) that we > are looking for, though I do realize that the code might be a bit much > to import.. As someone who recently stuffed libmagic into a very constrained sandbox environment, I can safely assert that you don't want to go there. The code isn't written in a way that would make this easy and I definitely wouldn't want it in the kernel. -- Brooks --tsOsTdHNUZQcU9Ye Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFQ9FTtXY6L6fI4GtQRAv4mAKCe6ty9ESLLQmvKYE5JETr9ATOMNgCgg8D+ 9qYBdes15mbVGBbdHm8A+Ds= =Rf1J -----END PGP SIGNATURE----- --tsOsTdHNUZQcU9Ye-- From owner-freebsd-arch@FreeBSD.ORG Mon Jan 14 19:37:07 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B4962623; Mon, 14 Jan 2013 19:37:07 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8FB1534A; Mon, 14 Jan 2013 19:37:07 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A04EBB95B; Mon, 14 Jan 2013 14:37:06 -0500 (EST) From: John Baldwin To: David Chisnall Subject: Re: Fast sigblock (AKA rtld speedup) Date: Mon, 14 Jan 2013 13:58:32 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <20130107182235.GA65279@kib.kiev.ua> <20130114174703.GB88220@stack.nl> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201301141358.33216.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 14 Jan 2013 14:37:06 -0500 (EST) Cc: toolchain@freebsd.org, Jilles Tjoelker , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 19:37:07 -0000 On Monday, January 14, 2013 1:24:04 pm David Chisnall wrote: > On 14 Jan 2013, at 17:47, Jilles Tjoelker wrote: > > > The code which does that check is actually under contrib/gcc. Problem > > is, they designed __gthread_active_p() to distinguish threaded and > > unthreaded programming environments -- it must be known in advance and > > cannot be changed later. The code for the unthreaded environment then > > takes advantage of this by not even allocating memory for mutexes in > > some cases. > > It's worth taking a step back and asking why this code exists at all, and the main reason is that acquiring a mutex used to be really expensive. It still is on some fruit-flavoured operating systems, but elsewhere it's a single atomic operation in the uncontended case, and in that case the cache line will already be exclusively owned by the calling core in single-threaded code. > > I would much rather that we followed the example of Solaris and made the multithreaded case fast and the default than keep piling on hacks that allow code to shave off a few clock cycles in the single-threaded case. In particular, the popularity of multicore systems means that it is increasingly rare for code to be both single threaded and performance critical, so this seems like misplaced optimisation. We have single-threaded performance critical applications that run on multicore systems (we just run several copies) and if we link in libthr, then pthread_mutex operations (even on uncontested locks) show up as one of the top consumers of CPU time when we profile our applications. > I strongly suspect that making it possible to inline the uncontended lock case for a pthread mutex and eliminating all of the branches on __isthreaded would give us a net speedup in both single and multithreaded cases. I'm less certain. Note that you can't inline mutex ops until you expose the mutexes themselves to userland (that is, making pthread_mutex_t not be opaque). -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Mon Jan 14 19:33:12 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7E74D3CE; Mon, 14 Jan 2013 19:33:12 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 666DD2B4; Mon, 14 Jan 2013 19:33:12 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (unknown [64.25.27.130]) by elvis.mu.org (Postfix) with ESMTPSA id 26D281A3CE7; Mon, 14 Jan 2013 11:33:10 -0800 (PST) Message-ID: <50F45D74.7000309@mu.org> Date: Mon, 14 Jan 2013 14:33:08 -0500 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: John Baldwin Subject: Re: svn commit: r243631 - in head/sys: kern sys References: <201211272119.qARLJxXV061083@svn.freebsd.org> <50F41F8C.5030900@freebsd.org> <50F4297F.8050708@FreeBSD.org> <201301141255.46994.jhb@freebsd.org> In-Reply-To: <201301141255.46994.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 14 Jan 2013 19:41:49 +0000 Cc: Adrian Chadd , src-committers@freebsd.org, Andre Oppermann , Alan Cox , "Jayachandran C." , Alexander Motin , Oleksandr Tymoshenko , freebsd-arch@freebsd.org, svn-src-head@freebsd.org, svn-src-all@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 19:33:12 -0000 On 1/14/13 12:55 PM, John Baldwin wrote: > On Monday, January 14, 2013 10:51:27 am Alexander Motin wrote: >> As I've actually written, there are two different things: >> ncallout -- number of preallocated callout structures for purposes of >> timeout() calls. That is a legacy API that is probably not very much >> used now, so that value don't need to be too big. But that allocation is >> static and if it will ever be exhausted system will panic. That is why >> it was set quite high. The right way now would be to analyze where that >> API is still used and estimate the really required number. > FYI, I have slowly been working through the tree fixing users of timeout() > to use callout_*() instead. > We would surely be in a bad place had you not taken so much time to fix nearly all those instances. It is very much appreciated. -Alfred From owner-freebsd-arch@FreeBSD.ORG Mon Jan 14 21:22:17 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3BA981D5; Mon, 14 Jan 2013 21:22:17 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) by mx1.freebsd.org (Postfix) with ESMTP id D844EB35; Mon, 14 Jan 2013 21:22:16 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r0ELMF9o019071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Jan 2013 13:22:15 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r0ELMFF4019070; Mon, 14 Jan 2013 13:22:15 -0800 (PST) (envelope-from jmg) Date: Mon, 14 Jan 2013 13:22:15 -0800 From: John-Mark Gurney To: John Baldwin Subject: Re: how long to keep support for gcc on x86? Message-ID: <20130114212215.GV1410@funkthat.com> Mail-Followup-To: John Baldwin , freebsd-arch@freebsd.org, Konstantin Belousov , Adrian Chadd References: <20130112233147.GK1410@funkthat.com> <20130113132402.GR2561@kib.kiev.ua> <201301141110.44165.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201301141110.44165.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Mon, 14 Jan 2013 13:22:15 -0800 (PST) Cc: Konstantin Belousov , Adrian Chadd , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 21:22:17 -0000 John Baldwin wrote this message on Mon, Jan 14, 2013 at 11:10 -0500: > On Sunday, January 13, 2013 8:24:02 am Konstantin Belousov wrote: > > On Sun, Jan 13, 2013 at 12:09:09AM -0800, Peter Wemm wrote: > > > On Sat, Jan 12, 2013 at 11:44 PM, Adrian Chadd wrote: > > > > > > > Thus I think adding clang-only code to the system right now is very, > > > > very premature. There still seem to be reasons to run systems on GCC > > > > instead of clang. > > > > > > I don't have a problem with it so long as the system isn't *broken* if > > > you're not using clang. ie: if the status-quo is maintained for gcc > > > systems and g-faster bits are enabled with clang. It's fine to > > > provide incentives to try clang, but it is not ok to regress the gcc > > > case. > > Absolutely agree. > > > > Please note that in the AES-NI case, gcc 'support' is only partially > > gcc issue, if gcc at all. Our 2.17 gas does not know about AES-NI > > mnemonics and cannot assemble them. > > It is not but so hard to add new instructions to binutils. I did it recently > for the xsave stuff as well the instructions needed by bhyve. How many > instructions are you talking about (and which ones)? Would adding them to binutils support inline assembly? Though supporting them in gas would be useful tool, but inline assembly would be best (so the compiler can do register allocation optimizations).. The instructions are aesenc, aesenclast, aesdec, aesdeclast.. And if you want to be complete, aeskeygenassist, aesimc, pclmulqdq... Though pclmulqdq isn't currently used... I'm willing to do some of the work and debugging too, just I don't know which files to modify, etc... I couldn't find any good guides on the internet that talks about this.. Thanks. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@FreeBSD.ORG Mon Jan 14 21:42:14 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 961ACC49 for ; Mon, 14 Jan 2013 21:42:14 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ye0-f169.google.com (mail-ye0-f169.google.com [209.85.213.169]) by mx1.freebsd.org (Postfix) with ESMTP id 4F826D02 for ; Mon, 14 Jan 2013 21:42:14 +0000 (UTC) Received: by mail-ye0-f169.google.com with SMTP id l13so745648yen.28 for ; Mon, 14 Jan 2013 13:42:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=CvRXRqJhqnX/BrCSi+8yqj0+OPwo80YIrtXe+XoVq0s=; b=a8DFo98TXBDVyzn7yWzAKnzHrW/rSssJ7JA3U7NSXiQ+Sd3veqBd0byBuuIqqoYIhY Bu/Sz0czNA98FXOgznoRllW/3jfmlzXPhUJKWqtgLAdDvF0rbVSGHy+DJUrWmUl0/oy4 TKxiMCrX62/2JUbt3UxtMlikVqz7CYSrIq1gAh+E47oXYzuBo5ix3e4dHpqb5sYl11IT hexslr5mysB+T1QJbhBU9+k2FK+hWpW3A4jeTrKIlGOVPjwr5NsAst3DUGJnBbHoi1lZ LRwdgMwPp+WEd7eIaaX/qHyKzAtVITaBjv7C2Q6b/obAZPnmaZMk2xnPz3ejX4kR7LdM DG3w== X-Received: by 10.236.89.107 with SMTP id b71mr94195867yhf.86.1358199728094; Mon, 14 Jan 2013 13:42:08 -0800 (PST) Received: from fusionlt2834a.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id v7sm8165062anh.5.2013.01.14.13.42.06 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 14 Jan 2013 13:42:06 -0800 (PST) Sender: Warner Losh Subject: Re: how long to keep support for gcc on x86? Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20130114212215.GV1410@funkthat.com> Date: Mon, 14 Jan 2013 14:42:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130112233147.GK1410@funkthat.com> <20130113132402.GR2561@kib.kiev.ua> <201301141110.44165.jhb@freebsd.org> <20130114212215.GV1410@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQnzbGZjcc1y1k56OqwD49sc4Q7k9jOrOaTiOsMw/F5UymBpd3ZDvt4nGUvHRawssntXJo3A Cc: Konstantin Belousov , Adrian Chadd , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 21:42:14 -0000 On Jan 14, 2013, at 2:22 PM, John-Mark Gurney wrote: > John Baldwin wrote this message on Mon, Jan 14, 2013 at 11:10 -0500: >> On Sunday, January 13, 2013 8:24:02 am Konstantin Belousov wrote: >>> On Sun, Jan 13, 2013 at 12:09:09AM -0800, Peter Wemm wrote: >>>> On Sat, Jan 12, 2013 at 11:44 PM, Adrian Chadd = wrote: >>>>=20 >>>>> Thus I think adding clang-only code to the system right now is = very, >>>>> very premature. There still seem to be reasons to run systems on = GCC >>>>> instead of clang. >>>>=20 >>>> I don't have a problem with it so long as the system isn't *broken* = if >>>> you're not using clang. ie: if the status-quo is maintained for = gcc >>>> systems and g-faster bits are enabled with clang. It's fine to >>>> provide incentives to try clang, but it is not ok to regress the = gcc >>>> case. >>> Absolutely agree. >>>=20 >>> Please note that in the AES-NI case, gcc 'support' is only partially >>> gcc issue, if gcc at all. Our 2.17 gas does not know about AES-NI >>> mnemonics and cannot assemble them. >>=20 >> It is not but so hard to add new instructions to binutils. I did it = recently=20 >> for the xsave stuff as well the instructions needed by bhyve. How = many=20 >> instructions are you talking about (and which ones)? >=20 > Would adding them to binutils support inline assembly? Though > supporting them in gas would be useful tool, but inline assembly would > be best (so the compiler can do register allocation optimizations).. Yes, of course. gcc, unlike clang, doesn't have a builtin assembler and = the inline assembler is passed through. With the proper register = annotation, gcc will do the proper register alloation, etc. > The instructions are aesenc, aesenclast, aesdec, aesdeclast.. And if > you want to be complete, aeskeygenassist, aesimc, pclmulqdq... Though > pclmulqdq isn't currently used... >=20 > I'm willing to do some of the work and debugging too, just I don't = know > which files to modify, etc... I couldn't find any good guides on the > internet that talks about this.. Warner From owner-freebsd-arch@FreeBSD.ORG Tue Jan 15 03:03:41 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DD0B4EEF; Tue, 15 Jan 2013 03:03:41 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail35.syd.optusnet.com.au (mail35.syd.optusnet.com.au [211.29.133.51]) by mx1.freebsd.org (Postfix) with ESMTP id 7566EF05; Tue, 15 Jan 2013 03:03:40 +0000 (UTC) Received: from c211-30-173-106.carlnfd1.nsw.optusnet.com.au (c211-30-173-106.carlnfd1.nsw.optusnet.com.au [211.30.173.106]) by mail35.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id r0F33PuS002157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Jan 2013 14:03:27 +1100 Date: Tue, 15 Jan 2013 14:03:25 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: John Baldwin Subject: Re: svn commit: r243631 - in head/sys: kern sys In-Reply-To: <201301141255.46994.jhb@freebsd.org> Message-ID: <20130115125138.P1099@besplex.bde.org> References: <201211272119.qARLJxXV061083@svn.freebsd.org> <50F41F8C.5030900@freebsd.org> <50F4297F.8050708@FreeBSD.org> <201301141255.46994.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=MscKcBme c=1 sm=1 a=PcN1GEuqyV8A:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=Y5AXMyR2jB0A:10 a=hIoxf_-hmCfl0XhHhqEA:9 a=CjuIK1q_8ugA:10 a=Lytp-BlQWYeEZU7Z:21 a=AhQzpKN3FgPaxGeD:21 a=TEtd8y5WR3g2ypngnwZWYw==:117 X-Mailman-Approved-At: Tue, 15 Jan 2013 03:13:39 +0000 Cc: Adrian Chadd , src-committers@FreeBSD.org, Andre Oppermann , Alan Cox , "Jayachandran C." , Alexander Motin , Alfred Perlstein , Oleksandr Tymoshenko , freebsd-arch@FreeBSD.org, svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 03:03:42 -0000 On Mon, 14 Jan 2013, John Baldwin wrote: > On Monday, January 14, 2013 10:51:27 am Alexander Motin wrote: >> As I've actually written, there are two different things: >> ncallout -- number of preallocated callout structures for purposes of >> timeout() calls. That is a legacy API that is probably not very much >> used now, so that value don't need to be too big. But that allocation is >> static and if it will ever be exhausted system will panic. That is why >> it was set quite high. The right way now would be to analyze where that >> API is still used and estimate the really required number. > > FYI, I have slowly been working through the tree fixing users of timeout() > to use callout_*() instead. But timeout() is a better API, starting with its name, for the simple cases that it handles. It is easier to use since the storage allocation for it is handled automatically. Since it returns a handle, the automatic storage allocation for it doesn't need to be static. (The allocation is not quite static, since ncallout is variable, but I will describe it as static.) The static allocation is just a minor optimization for efficiency and simplicity (the callout API gives further minor optimizations by allocating even more statically in callers, so that no linked list management is needed and there is better locality). It can be replaced by a malloc() on every call to timeout(), or maybe a buffer pool. The static allocation is equivalent to a buffer pool that is never expanded and has no fallback to malloc() when it is too small. Since there is no fallback, the pool has to be very large (but not 512MB) to prevent panics. Since use of timeout() has rotted, there aren't many callers of it left, so if there was a fallback then a very small buffer pool of size say 16 entries would suffice. Larger systems and newer ones that start using the better timeout() API might need as many as 256 entries. However, buffer pools are what you use when the system's malloc() is too slow to use. Since malloc(9) or at least uma_zalloc(9) is not all that slow, it is probably efficient enough to just use it, at least while timeout() is just a compatibility wrapper. There are already some minor efficiencies from using the wrapper. By using the system's malloc() and not using a buffer pool, timeout() becomes even simpler than before: delete ncallout and all associated code, and replace the linked list by malloc()'s internal management: % struct callout_handle % timeout(ftn, arg, to_ticks) % timeout_t *ftn; % void *arg; % int to_ticks; % { % struct callout_cpu *cc; % struct callout *new; % struct callout_handle handle; % % cc = CC_CPU(timeout_cpu); % CC_LOCK(cc); All the locking becomes unnecessary too. The locking might be just as slow as dynamic allocation, especially if the lock is contended. % /* Fill in the next free callout structure. */ % new = SLIST_FIRST(&cc->cc_callfree); This would have to be malloc()ed. There seems to be a problem with waiting being impossible in some contexts, so malloc() might fail, but this function can't fail. So a large buffer pool might be needed after all to handle cases where malloc() fails :-(. Also, it must be checked that there are no caller's of timeout() before malloc() is initialized, or else the current early initialization of the buffer pool is still needed for these early callers. % if (new == NULL) % /* XXX Attempt to malloc first */ % panic("timeout table full"); This code always knew that it shouldn't panic. % SLIST_REMOVE_HEAD(&cc->cc_callfree, c_links.sle); % callout_reset(new, to_ticks, ftn, arg); % handle.callout = new; % CC_UNLOCK(cc); % % return (handle); % } Bruce From owner-freebsd-arch@FreeBSD.ORG Tue Jan 15 04:46:40 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DAF77F90 for ; Tue, 15 Jan 2013 04:46:40 +0000 (UTC) (envelope-from grehan@freebsd.org) Received: from alto.onthenet.com.au (alto.OntheNet.com.au [203.13.68.12]) by mx1.freebsd.org (Postfix) with ESMTP id 9C032759 for ; Tue, 15 Jan 2013 04:46:40 +0000 (UTC) Received: from dommail.onthenet.com.au (dommail.OntheNet.com.au [203.13.70.57]) by alto.onthenet.com.au (Postfix) with ESMTPS id 453A111BAC for ; Tue, 15 Jan 2013 14:46:33 +1000 (EST) Received: from Peter-Grehans-MacBook-Pro.local (c-75-71-5-126.hsd1.co.comcast.net [75.71.5.126]) by dommail.onthenet.com.au (MOS 4.2.4-GA) with ESMTP id BJI36522 (AUTH peterg@ptree32.com.au); Tue, 15 Jan 2013 14:46:32 +1000 Message-ID: <50F4DF1D.2080800@freebsd.org> Date: Mon, 14 Jan 2013 21:46:21 -0700 From: Peter Grehan User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20 MIME-Version: 1.0 To: "freebsd-arch@freebsd.org" Subject: Re: [RFC] Moving bhyve to head References: <50ECFD6C.4000408@freebsd.org> In-Reply-To: <50ECFD6C.4000408@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 04:46:40 -0000 > Comments and review requested :) We haven't heard anything major, so will move ahead with this. Hoping to get it into -current by Thursday. later, Peter. From owner-freebsd-arch@FreeBSD.ORG Tue Jan 15 09:21:37 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A2039B36; Tue, 15 Jan 2013 09:21:37 +0000 (UTC) (envelope-from theraven@freebsd.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id 5747D78F; Tue, 15 Jan 2013 09:21:37 +0000 (UTC) Received: from [192.168.0.2] (cpc10-cmbg15-2-0-cust123.5-4.cable.virginmedia.com [86.30.246.124]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r0F9LThB017760 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Tue, 15 Jan 2013 09:21:30 GMT (envelope-from theraven@freebsd.org) Subject: Re: Fast sigblock (AKA rtld speedup) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: David Chisnall In-Reply-To: <201301141358.33216.jhb@freebsd.org> Date: Tue, 15 Jan 2013 09:21:25 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130107182235.GA65279@kib.kiev.ua> <20130114174703.GB88220@stack.nl> <201301141358.33216.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1278) Cc: toolchain@freebsd.org, Jilles Tjoelker , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 09:21:37 -0000 On 14 Jan 2013, at 18:58, John Baldwin wrote: > I'm less certain. Note that you can't inline mutex ops until you = expose > the mutexes themselves to userland (that is, making pthread_mutex_t = not > be opaque). This is one of the things that will be required anyway if we wish to = support process-shared mutexes (they've been in POSIX since 1997, so = it's probably getting on for time we did), as the current = mutex-is-a-pointer implementation depends on the virtual address space = of the creator, and so does not work if the mutex is created in a shared = memory segment. That said, even with the current implementation we wouldn't need to = expose the entire mutex structure, just the word that is used as the = fast path. The inline version would be something like: struct pthread_mutex_header { _Atomic(long) lock_word; // other private fields not exposed in header; }; typedef struct pthread_mutex_header *pthread_mutex_t; // Implementation in libthr / libc, which calls into the kernel. int pthread_mutex_lock_slowly(pthread_mutex_t*); inline int pthread_mutex_lock(pthread_mutex_t *mutex) { int desired =3D 0; if (atomic_compare_exchange_weak_explicit(&(*mutex)->lock_word, = &desired, 1, memory_order_acquire, memory_order_relaxed)) return 0; return pthread_mutex_lock_slowly(mutex); } The slow path is only needed when the mutex can't be acquired trivially = in userspace. On x86, the fast path adds 6 extra instructions, including = a branch that can be statically hinted if we want (assume that we won't = be going down the slow path, because a mispredicted branch doesn't add = much to the cost of the syscall if we are). =20 The corresponding saving is that we get to delete a massive pile of = conditionals that we currently have for __is_threaded. We'd also = completely avoid the function call (which is actually two function = calls, as we do some trampoline things in libc) in the fast-path case = for threaded applications. A similar saving is possible with read-write locks and possibly with = condition variables, although our kernel interface for these is = incredibly poorly documented (for once, Linux actually has better = documentation: futexes are very well documented). Looking in umtx.h, it = sort-of exposes inline functions that look like this, but given the = complete lack of documentation, I have no idea how useable they are. =20 David= From owner-freebsd-arch@FreeBSD.ORG Tue Jan 15 20:27:58 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 98D3F8BA; Tue, 15 Jan 2013 20:27:58 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 71DA0645; Tue, 15 Jan 2013 20:27:58 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id CA5E0B918; Tue, 15 Jan 2013 15:27:57 -0500 (EST) From: John Baldwin To: David Chisnall Subject: Re: Fast sigblock (AKA rtld speedup) Date: Tue, 15 Jan 2013 14:45:26 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <20130107182235.GA65279@kib.kiev.ua> <201301141358.33216.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201301151445.26895.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 15 Jan 2013 15:27:57 -0500 (EST) Cc: toolchain@freebsd.org, Jilles Tjoelker , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 20:27:58 -0000 On Tuesday, January 15, 2013 4:21:25 am David Chisnall wrote: > On 14 Jan 2013, at 18:58, John Baldwin wrote: > > > I'm less certain. Note that you can't inline mutex ops until you expose > > the mutexes themselves to userland (that is, making pthread_mutex_t not > > be opaque). > > This is one of the things that will be required anyway if we wish to support process-shared mutexes (they've been in POSIX since 1997, so it's probably getting on for time we did), as the current mutex-is-a-pointer implementation depends on the virtual address space of the creator, and so does not work if the mutex is created in a shared memory segment. Yes, David Xu has a p4 branch with this done already. My point is that I would rather effort be spent on getting that in before attempting your suggestion for our current primitives as the inlining you do now requires that David's changes honor the same ABI in the future. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Jan 16 00:30:39 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 099CD997; Wed, 16 Jan 2013 00:30:39 +0000 (UTC) (envelope-from listlog2011@gmail.com) Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) by mx1.freebsd.org (Postfix) with ESMTP id A8B8189A; Wed, 16 Jan 2013 00:30:38 +0000 (UTC) Received: by mail-pa0-f46.google.com with SMTP id bh2so433900pad.5 for ; Tue, 15 Jan 2013 16:30:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:reply-to:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=cYvtlBtpMeYM3HqF+sARSGxitLS5o0WxtfxLkJus1TE=; b=uu3F3jpjuMOxPGmbGLSULzU836KHfdkJCq7xYoygksrjvd8c3r90BC01fygqQFqsIx OeMyEkZqhnf78aWKza+QSZptZZOPDDWk0kD6JLa2ecyoL2FhITZw5spKujJJuUq2nLDN zwJ+Pv7fhSfsbHKELvNVCQxrRIuvpxp6GYZFRdJEO9Yr4Ld14CN7TEqhoPIzQ0G3EN8h h4svv6wTEark7zySAJ4CGyaJZx+7MxPuVLiIP+QxPr+Tg5NbnI19tiIDSRtCB66mv1hn ZzosoQtgyEqcF8FGfU49YjomFz9EDOQqUqksxjZ5DHfRopGJrGNBk6/8Va9Z4/3x/Kj7 Ec0A== X-Received: by 10.68.252.4 with SMTP id zo4mr273293689pbc.126.1358296233913; Tue, 15 Jan 2013 16:30:33 -0800 (PST) Received: from xp5k.my.domain ([115.192.139.240]) by mx.google.com with ESMTPS id kl3sm11114067pbc.15.2013.01.15.16.30.29 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Jan 2013 16:30:32 -0800 (PST) Message-ID: <50F5F4A2.6080200@gmail.com> Date: Wed, 16 Jan 2013 08:30:26 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: John Baldwin Subject: Re: Fast sigblock (AKA rtld speedup) References: <20130107182235.GA65279@kib.kiev.ua> <201301141358.33216.jhb@freebsd.org> <201301151445.26895.jhb@freebsd.org> In-Reply-To: <201301151445.26895.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: toolchain@freebsd.org, David Chisnall , Jilles Tjoelker , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: davidxu@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 00:30:39 -0000 On 2013/01/16 03:45, John Baldwin wrote: > On Tuesday, January 15, 2013 4:21:25 am David Chisnall wrote: >> On 14 Jan 2013, at 18:58, John Baldwin wrote: >> >>> I'm less certain. Note that you can't inline mutex ops until you expose >>> the mutexes themselves to userland (that is, making pthread_mutex_t not >>> be opaque). >> This is one of the things that will be required anyway if we wish to support > process-shared mutexes (they've been in POSIX since 1997, so it's probably > getting on for time we did), as the current mutex-is-a-pointer implementation > depends on the virtual address space of the creator, and so does not work if > the mutex is created in a shared memory segment. > > Yes, David Xu has a p4 branch with this done already. My point is that I > would rather effort be spent on getting that in before attempting your > suggestion for our current primitives as the inlining you do now requires > that David's changes honor the same ABI in the future. > Yes, I have such a p4 branch. The problem I encountered is binary compatibility, libthr has to have both code for old mutex which is a pointer and new mutex which is a structure, if module A passes pointer-mutex to a recompiled module B which is using structure-mutex, this is broken. And I found NVIDIA GeForce driver is using dlsym() with no version hint, it is trying to get pthread_mutex_lock and other symbols, the default version in the new libthr will return a new entry which uses structure mutex, since the driver is not open-source, so you can not recompile it, the change will break it. Regards, David Xu From owner-freebsd-arch@FreeBSD.ORG Wed Jan 16 02:46:27 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2E4A54D7; Wed, 16 Jan 2013 02:46:27 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x229.google.com (wg-in-x0229.1e100.net [IPv6:2a00:1450:400c:c00::229]) by mx1.freebsd.org (Postfix) with ESMTP id 91781FB6; Wed, 16 Jan 2013 02:46:26 +0000 (UTC) Received: by mail-wg0-f41.google.com with SMTP id ds1so2351988wgb.0 for ; Tue, 15 Jan 2013 18:46:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=hh7J6OSV78Gi7iZs9o1crZRgGtgVqVY74b3cak55KxY=; b=Xacord8sr05yHht4Db1Pb9H5Upsyvww437JUjfycIWPHwqlWAGGIMYxa6niAGpykEq JtRiHjs9O1KvNdBVNccLkdIyCw5VmVoR4DpZzxELC9M2UaEjdnayGIIzyBlcs0UKt7bJ HxbwDsZnxuY0nXF6QdlKVxlKzOxAdLrSyIBrppsHG3Ah8rpkQ1YoMCvPLKu1pKIYEtkW OQqCOhmrRPhXvFPDNnckOEd5bVdczvQ0zKisyf6EaBwhn5aY2cYiC8v2YRdk7B6l/Hx7 zICBVWsOnzqn/zdp5gd1WyIIKZVpudgEIIsorvEzzJ1UsWGufG+EuZCjHbWOT6+QHpP5 v9kw== MIME-Version: 1.0 Received: by 10.180.100.163 with SMTP id ez3mr7021580wib.32.1358304385825; Tue, 15 Jan 2013 18:46:25 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Tue, 15 Jan 2013 18:46:25 -0800 (PST) Date: Tue, 15 Jan 2013 18:46:25 -0800 X-Google-Sender-Auth: rBt-Ey9jYmq3KphX3ODJwFPlmYI Message-ID: Subject: [RFC] add gdb into the cross-build target From: Adrian Chadd To: freebsd-arch@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 02:46:27 -0000 Hi, I'd like to propose adding gdb into the cross-build target. This way MIPS, ARM, PPC etc targets will have gdb- built in the cross-build environment, so it can be (hopefully) used for cross-build debugging of the kernel, as well as remote debugging out of the box. Here's my example patch. Thanks! Adrian Index: Makefile.inc1 =================================================================== --- Makefile.inc1 (revision 245281) +++ Makefile.inc1 (working copy) @@ -1211,6 +1211,7 @@ ${_clang_libs} \ ${_clang} \ ${_binutils} \ + gnu/usr.bin/gdb \ ${_cc} \ usr.bin/xlint/lint1 usr.bin/xlint/lint2 usr.bin/xlint/xlint \ ${_btxld} \ @@ -1673,6 +1674,7 @@ .for _tool in \ gnu/usr.bin/binutils \ gnu/usr.bin/cc \ + gnu/usr.bin/gdb \ usr.bin/ar ${_+_}@${ECHODIR} "===> xdev ${_tool} (obj,depend,all)"; \ cd ${.CURDIR}/${_tool}; \ @@ -1699,6 +1701,7 @@ .for _tool in \ gnu/usr.bin/binutils \ gnu/usr.bin/cc \ + gnu/usr.bin/gdb \ usr.bin/ar ${_+_}@${ECHODIR} "===> xdev ${_tool} (install)"; \ cd ${.CURDIR}/${_tool}; \ From owner-freebsd-arch@FreeBSD.ORG Thu Jan 17 05:16:56 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2BAB72C0 for ; Thu, 17 Jan 2013 05:16:56 +0000 (UTC) (envelope-from cfd@cfdhome.com) Received: from nat.cfdhome.com (cfdhome.com [67.100.119.58]) by mx1.freebsd.org (Postfix) with ESMTP id D399E392 for ; Thu, 17 Jan 2013 05:16:55 +0000 (UTC) Received: from nat.cfdhome.com (localhost [127.0.0.1]) by nat.cfdhome.com (8.14.6/8.14.5) with ESMTP id r0H5BFQx005199 for ; Wed, 16 Jan 2013 21:11:15 -0800 (PST) (envelope-from cfd@cfdhome.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cfdhome.com; s=first; t=1358399475; bh=W6AvhFxjJYSOGTnno2qqOVqEB2uFBmWNZkxXNZ295y4=; h=Subject:From:To:In-Reply-To:References:Date; b=qJoNysTjOJGJvMmz6h/IlggFvD67Rf3hrVK0NDaTJpA9Pg5s00y5AXKqQwfn/iUbk Zx8nHEByEA3uUEM/KX01U/G/LJW5fMcThJ8+UZCkY816YbcgSdYI3/9nxNBJemXxkT QEQiu2YgL5OGhkHzI/XWhm7hDqOT069m7XakjueA= Received: (from cfd@localhost) by nat.cfdhome.com (8.14.6/8.14.6/Submit) id r0H5BF3Y005198 for freebsd-arch@freebsd.org; Wed, 16 Jan 2013 21:11:15 -0800 (PST) (envelope-from cfd@cfdhome.com) X-Authentication-Warning: nat.cfdhome.com: cfd set sender to cfd@cfdhome.com using -f Subject: Re: LLVM Image Activator From: Charles DeBardeleben To: freebsd-arch@freebsd.org In-Reply-To: <20130114185646.GB15933@lor.one-eyed-alien.net> References: <50E9BC2D.7000302@freebsd.org> <201301070936.39052.jhb@freebsd.org> <20130107172433.GX82219@kib.kiev.ua> <20130113132057.GQ2561@kib.kiev.ua> <50F2DF11.50202@freebsd.org> <20130113171304.GZ2561@kib.kiev.ua> <50F2F97B.5030306@freebsd.org> <20130113202435.GN1410@funkthat.com> <20130114185646.GB15933@lor.one-eyed-alien.net> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Jan 2013 21:11:15 -0800 Message-ID: <1358399475.2860.56.camel@nat.cfdhome.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 05:16:56 -0000 Just adding my $0.02 to the architectural concept of the use of magic numbers. I believe that the whole concept if using any form of the data content of a file to decide what should should interpret the data is flawed. I believe that this information is properly stored as meta-data of the file, which for UNIX would probably most naturally be part of the inode. I think that main reason we rely on "magic" for this is an over reaction of original UNIX authors to not having been granted permission to set this part of meta-data in their past. Now, given the long history of using magic numbers this way, I doubt that they will go away. However, there currently is still very little use of magic numbers in the base kernel. I have to wonder if it may be a better idea to think about a general mechanism to have the meta-data of a file have an explicit "interpreter" or perhaps even a more general "access method" vector rather than begin the process of importing libmagic into the kernel. -Charles On Mon, 2013-01-14 at 12:56 -0600, Brooks Davis wrote: > On Sun, Jan 13, 2013 at 12:24:35PM -0800, John-Mark Gurney wrote: > > Nathan Whitehorn wrote this message on Sun, Jan 13, 2013 at 10:14 -0800= : > > > On 01/13/13 09:13, Konstantin Belousov wrote: > > > > On Sun, Jan 13, 2013 at 08:21:37AM -0800, Nathan Whitehorn wrote: > > > >> On 01/13/13 05:20, Konstantin Belousov wrote: > > > >>> On Sun, Jan 13, 2013 at 12:41:09PM +0100, Ed Schouten wrote: > > > >>>> Hi Kostik, > > > >>>> > > > >>>> 2013/1/7 Konstantin Belousov : > > > >>>>> I still do remember the buzz about the binary format 0xCAFEBABE= , which > > > >>>>> AFAIR gained image activator support on several OSes, to be gar= bage > > > >>>>> collected. > > > >>>> > > > >>>> Maybe it would then be a good idea then to add some kind of gene= ral > > > >>>> purpose remapping imgact? Example: > > > >>>> > > > >>>> /etc/imgacttab: > > > >>>> > > > >>>> cafebabe /usr/local/bin/java > > > >>>> cffaedfe /usr/local/bin/osx_emulator > > > >>>> 4243c0de /usr/bin/lli > > > >>>> > > > >>>> That way we still give people the freedom to play around with ma= pping > > > >>>> their own executable formats, but don't need to maintain a bunch= of > > > >>>> imgacts. > > > >>> > > > >>> A generic module that could be somewhat customized at runtime to = map > > > >>> offset+signature into the shebang path could be a possibility ind= eed. > > > >>> I strongly prefer to have it as module and not enabled by default= . > > > >>> > > > >>> Asking Nathan for writing the thing is too much, IMHO, esp. in > > > >>> the response to the 50-lines hack. > > > >>> > > > >> > > > >> I think this is a good idea, since it both prevents a profusion of > > > >> similar activators and works nicely in jails and similar environme= nts. I > > > >> probably won't write it quickly, but it should not take more than = about > > > >> 50 lines, so I can't imagine it will be that bad. There are some > > > >> complications with this kind of design from the things in the XXX > > > >> comment in imgact_llvm.c about handling argv[0] that I need to thi= nk > > > >> some more about. > > > > Great. I do not believe in the 50 lines, but I am happy that you wa= nt > > > > to work this out. > > > >=20 > > > >> > > > >> Why are you opposed to having it there by default? I think it's ac= tually > > > >> quite important that it be there by default. Having it not "standa= rd" > > > >> would be fine, but it should at least be in GENERIC. There are min= imal > > > >> security risks since it just munges begin_argv and doesn't even lo= ad the > > > >> executable and it's little enough code that there should not be an= y > > > >> kernel bloat to speak of. If things like this aren't enabled by de= fault, > > > >> no one can depend on them being there, no one will use it, and the= point > > > >> is entirely lost. > > > > All image activators demonstrated a constant stream of security hol= es. > > > > Even our ELF activator, and I was guilty there too. > > > >=20 > > > > I definitely do not fight over the inclusion of the proposed activa= tor > > > > into GENERIC, but do insist on the config option + module. > > > >=20 > > >=20 > > > OK, that sounds like a plan then. I'll try to code up something > > > configurable in the next couple weeks, unless someone else beats me t= o it. > >=20 > > I'll point out that file already has the magic (pun intended) that we > > are looking for, though I do realize that the code might be a bit much > > to import.. >=20 > As someone who recently stuffed libmagic into a very constrained sandbox > environment, I can safely assert that you don't want to go there. The > code isn't written in a way that would make this easy and I definitely > wouldn't want it in the kernel. >=20 > -- Brooks From owner-freebsd-arch@FreeBSD.ORG Thu Jan 17 10:46:06 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 67A22AE0 for ; Thu, 17 Jan 2013 10:46:06 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 23968252 for ; Thu, 17 Jan 2013 10:46:06 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id F2C0C8A50F; Thu, 17 Jan 2013 10:45:58 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id r0HAjvPb081822; Thu, 17 Jan 2013 10:45:58 GMT (envelope-from phk@phk.freebsd.dk) To: Charles DeBardeleben Subject: Re: LLVM Image Activator In-reply-to: <1358399475.2860.56.camel@nat.cfdhome.com> From: "Poul-Henning Kamp" References: <50E9BC2D.7000302@freebsd.org> <201301070936.39052.jhb@freebsd.org> <20130107172433.GX82219@kib.kiev.ua> <20130113132057.GQ2561@kib.kiev.ua> <50F2DF11.50202@freebsd.org> <20130113171304.GZ2561@kib.kiev.ua> <50F2F97B.5030306@freebsd.org> <20130113202435.GN1410@funkthat.com> <20130114185646.GB15933@lor.one-eyed-alien.net> <1358399475.2860.56.camel@nat.cfdhome.com> Date: Thu, 17 Jan 2013 10:45:57 +0000 Message-ID: <81821.1358419557@critter.freebsd.dk> Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 10:46:06 -0000 Content-Type: text/plain; charset=ISO-8859-1 -------- In message <1358399475.2860.56.camel@nat.cfdhome.com>, Charles DeBardeleben wri tes: >I have to wonder if it may >be a better idea to think about a general mechanism to have the >meta-data of a file [...] Look at UFS Extended Attributes ? When we did UFS2, I tried to make Kirk give directories a magic header too: "#!/bin/ls\n" I think that's the only time I've managed to leave Kirk speech-less :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Thu Jan 17 14:14:03 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E5896E1C; Thu, 17 Jan 2013 14:14:03 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id B258FFD; Thu, 17 Jan 2013 14:13:50 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id r0HEDoDc091020; Thu, 17 Jan 2013 07:13:50 -0700 (MST) (envelope-from ian@FreeBSD.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r0HEDltk006354; Thu, 17 Jan 2013 07:13:47 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: [RFC/RFT] calloutng From: Ian Lepore To: Bruce Evans In-Reply-To: <20130114102118.V1045@besplex.bde.org> References: <50CCAB99.4040308@FreeBSD.org> <50CE5B54.3050905@FreeBSD.org> <50D03173.9080904@FreeBSD.org> <20121225232126.GA47692@alchemy.franken.de> <50DB4EFE.2020600@FreeBSD.org> <20130106152313.GD26039@alchemy.franken.de> <50EBF921.2000304@FreeBSD.org> <20130113180940.GM26039@alchemy.franken.de> <50F30CAB.3000001@FreeBSD.org> <20130114102118.V1045@besplex.bde.org> Content-Type: text/plain; charset="us-ascii" Date: Thu, 17 Jan 2013 07:13:47 -0700 Message-ID: <1358432027.32417.213.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Davide Italiano , Marius Strobl , Alexander Motin , FreeBSD Current , freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 14:14:04 -0000 On Mon, 2013-01-14 at 11:38 +1100, Bruce Evans wrote: > On Sun, 13 Jan 2013, Alexander Motin wrote: > > > On 13.01.2013 20:09, Marius Strobl wrote: > >> On Tue, Jan 08, 2013 at 12:46:57PM +0200, Alexander Motin wrote: [...] > > > > In existing code in HEAD and 9 timecounters are never called with spin > > mutex held. I intentionally tried to avoid that in existing eventtimers > > code. > > Er, timecounters are called with a spin mutex held in existing code: > though it is dangerous to do so, timecounters are called from fast > interrupt handlers for very timekeeping-critical purposes: > - to implement the TIOCTIMESTAMP ioctl (except this is broken in > -current). This was a primitive version of pps timestamping. > - for pps timestamping. The interrupt handler (which should be a fast > interrupt handler to minimize latency) calls pps_capture() which > calls tc_get_timecount() and does other "lock-free" accesses to the > timecounter state. This still works in -current (at least there is > still code for it). > Unfortunately, calling pps_capture() in the primary interrupt context is no longer an option with the stock pps driver. Ever since the ppbus rewrite all ppbus children must use threaded handlers. I tried to fix that a couple different ways, and both ended up with crazy-complex code scattered around the ppbus family just to support the rarely-used pps capture. It would have been easier to do if filter and threaded interrupt handlers had the same function signature. I ended up writting a separate driver that can be used instead of ppc + ppbus + pps, since anyone who cares about precise pps capture is unlikely to be sharing the port with a printer or plip device or some such. > OTOH, all drivers that call pps_capture() from their interrupt handler > then immediately call pps_event(). This has always been very broken, > and became even more broken with SMPng. pps_event() does many more > timecounter and pps accesses whose locking is unclear at best, and > in some configurations it calls hardpps(), which is only locked by > Giant, despite comments in kern_ntptime.c still saying that it (and > many other functions in kern_ntptime.c) must be called at splclock() > or higher. splclock() is of course now null, but the locking > requirements in kern_ntptime.c haven't changed much. kern_ntptime.c > always needed to be locked by the equivalent of a spin mutex, which > is stronger locking than was given by splclock(). pps_event() would > have to aquire the spin mutex before calling hardpps(), although > this is bad for fast interrupt handlers. The correct implementation > is probably to only do the capture part from fast interrupt handlers. > In my rewritten dedicated pps driver I call pps_capture() from the filter handler and pps_event() from the threaded handler. I never found any good documentation on the low-level details of this stuff, and there isn't enough good example code to work from. My hazy memory is that I ended up studying the pps_capture() and pps_event() code enough to infer that their design intent seems to be to allow you to capture with no locking and do the event processing later in some sort of deferred or threaded context. > > Callout code same time can be called in any environment with any > > locks held. And new callout code may need to know precise current time > > in any of those conditions. Attempt to use an IPI and wait there can be > > fatal. > > Callout code can't be called from such a general "any" environment as > timecounter code. Not from a fast interrupt handler. Not from an NMI > or IPI handler. I hope. But timecounter code has a good chance of > working even for the last 2 environments, due to its design requirement > of working in the first. > > The spinlock in the i8254 timecounter certainly breaks some cases. > For example, suppose the lock is held for a timecounter read from > normal context. It masks hardware interrupts on the current CPU (except > in my version). It doesn't mask NMIs or other traps. So if the NMI > or other trap handler does a timecounter hardware call, there is > deadlock in at least the !SMP case. In my version, it blocks normal > interrupts later if they occur, but doesn't block fast interrupts, so > the pps_capture() call would deadlock if it occurs, like a timecounter > call from an NMI. I avoid this by not using pps in any fast interrupt > handler, and by only using the i8254 timecounter for testing. I do > use pps in a (nonstandard) x86 RTC clock interrupt handler. My clock > interrupt handlers are all non-fast to avoid this and other locking > problems. Hrm, now you've got me a bit worried about capturing in the primary context. Not that I have much option, on a 300mhz Geode and similar wimpy embedded processors there's enough latency on a theaded handler that the pps signal can be de-asserted by time the handler runs (precision timing gear often outputs a very narrow pps pulse, 1 - 10uS isn't uncommon). I know I don't have to worry about NMIs on the systems in question, but I'm not so sure about "other trap handler". > [...] > > Bruce -- Ian From owner-freebsd-arch@FreeBSD.ORG Thu Jan 17 16:05:51 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 59504B7A; Thu, 17 Jan 2013 16:05:51 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 3554FA75; Thu, 17 Jan 2013 16:05:51 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id r0HG5o8w092227; Thu, 17 Jan 2013 09:05:50 -0700 (MST) (envelope-from ian@FreeBSD.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r0HG5mdZ006465; Thu, 17 Jan 2013 09:05:48 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: [RFC/RFT] calloutng From: Ian Lepore To: Davide Italiano In-Reply-To: <1356909223.54953.74.camel@revolution.hippie.lan> References: <50CCAB99.4040308@FreeBSD.org> <50CE5B54.3050905@FreeBSD.org> <50D03173.9080904@FreeBSD.org> <20121225232126.GA47692@alchemy.franken.de> <50DB4EFE.2020600@FreeBSD.org> <1356909223.54953.74.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Thu, 17 Jan 2013 09:05:47 -0700 Message-ID: <1358438747.32417.223.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Marius Strobl , Alexander Motin , FreeBSD Current , freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 16:05:51 -0000 On Sun, 2012-12-30 at 16:13 -0700, Ian Lepore wrote: > On Wed, 2012-12-26 at 21:24 +0200, Alexander Motin wrote: > >[...] > > > > I grabbed testsleep.c to test an arm event timer implementation, and had > to fix a couple nits... kqueueto was missing from the names[] array, and > I had to add a "* 1000" to a couple places where usec was stuffed into a > timespec's tv_nsec. > > I also tested the calloutng_12_17 patches and the kqueue stuff behaved > very strangely. Then I noticed you had a 12_26 patchset so I tested > that (after crudely fixing a couple uninitialized var warnings), and it > all looks good on this arm (Raspberry Pi). I'll attach the results. > > It's so sweet to be able to do precision sleeps. > > -- Ian > > > plain text document attachment (calloutng_test.txt) > for t in 1 300 3000 30000 300000 ; do > for m in select poll usleep nanosleep kqueue kqueueto syscall ; do > ./testsleep $t $m > done > done > > > With calloutng_12_26.patch... > > HZ=100 HZ=250 HZ=1000 > ---------- ---------------- ---------------- ---------------- > select 1 55.79 1 50.96 1 61.32 > poll 1 1109.46 1 1107.86 1 1114.38 > usleep 1 56.33 1 72.90 1 62.78 > nanosleep 1 52.66 1 55.23 1 64.23 > kqueue 1 1114.23 1 1113.81 1 1121.21 > kqueueto 1 65.44 1 71.00 1 75.01 > syscall 1 4.70 1 4.45 1 4.55 > select 300 355.79 300 357.76 300 362.35 > poll 300 1107.85 300 1122.55 300 1115.62 > usleep 300 355.28 300 357.28 300 360.79 > nanosleep 300 354.49 300 355.82 300 360.62 > kqueue 300 1112.57 300 1118.13 300 1117.16 > kqueueto 300 375.98 300 378.62 300 395.61 > syscall 300 4.41 300 4.45 300 4.54 > select 3000 3246.75 3000 3246.74 3000 3252.72 > poll 3000 3238.10 3000 3229.12 3000 3250.10 > usleep 3000 3242.47 3000 3237.06 3000 3249.61 > nanosleep 3000 3238.79 3000 3231.55 3000 3248.11 > kqueue 3000 3240.01 3000 3236.07 3000 3247.60 > kqueueto 3000 3265.36 3000 3267.22 3000 3274.96 > syscall 3000 4.69 3000 4.44 3000 4.50 > select 30000 31714.60 30000 31941.17 30000 32467.69 > poll 30000 31522.76 30000 31983.00 30000 32497.81 > usleep 30000 31459.67 30000 31980.76 30000 32458.71 > nanosleep 30000 31431.02 30000 31982.22 30000 32525.20 > kqueue 30000 31466.75 30000 31873.90 30000 31973.54 > kqueueto 30000 31564.67 30000 32522.35 30000 32475.59 > syscall 30000 4.70 30000 4.73 30000 4.89 > select 300000 319133.02 300000 311562.33 300000 309918.62 > poll 300000 319604.27 300000 311422.94 300000 310000.76 > usleep 300000 319314.60 300000 311269.69 300000 309996.34 > nanosleep 300000 319497.58 300000 311425.40 300000 309997.13 > kqueue 300000 309995.55 300000 303980.27 300000 309908.82 > kqueueto 300000 319505.88 300000 311424.97 300000 309996.16 > syscall 300000 4.41 300000 4.45 300000 4.89 > > > With no patches... > > HZ=100 HZ=250 HZ=1000 > ---------- ---------------- ---------------- ---------------- > select 1 19941.70 1 7989.10 1 1999.16 > poll 1 19904.61 1 7987.32 1 1999.78 > usleep 1 19904.95 1 7993.30 1 1999.96 > nanosleep 1 19905.64 1 7993.71 1 1999.72 > kqueue 1 10001.61 1 4004.00 1 1000.27 > kqueueto 1 19904.00 1 7993.03 1 1999.54 > syscall 1 4.04 1 4.05 1 4.75 > select 300 19904.66 300 7998.39 300 2000.27 > poll 300 19904.35 300 7993.47 300 1999.86 > usleep 300 19903.96 300 7994.11 300 1999.81 > nanosleep 300 19904.48 300 7993.77 300 1999.80 > kqueue 300 10001.68 300 4004.18 300 1000.31 > kqueueto 300 19997.86 300 7993.37 300 1999.59 > syscall 300 4.01 300 4.00 300 4.32 > select 3000 19904.80 3000 7998.85 3000 3998.43 > poll 3000 19904.92 3000 8005.93 3000 3999.39 > usleep 3000 19904.50 3000 7992.88 3000 3999.44 > nanosleep 3000 19904.84 3000 7993.34 3000 3999.36 > kqueue 3000 10001.58 3000 4003.97 3000 3000.72 > kqueueto 3000 19903.56 3000 7993.24 3000 3999.34 > syscall 3000 4.02 3000 4.37 3000 4.29 > select 30000 39905.02 30000 35991.79 30000 31051.77 > poll 30000 39905.49 30000 35980.35 30000 30995.64 > usleep 30000 39903.78 30000 35979.48 30000 30995.23 > nanosleep 30000 39904.55 30000 35981.61 30000 30995.87 > kqueue 30000 30002.73 30000 32019.54 30000 30004.83 > kqueueto 30000 39903.59 30000 35979.64 30000 30996.05 > syscall 30000 4.44 30000 4.04 30000 4.31 > select 300000 310001.23 300000 303995.86 300000 300994.30 > poll 300000 309902.73 300000 303981.58 300000 300996.17 > usleep 300000 309903.64 300000 303980.17 300000 300997.42 > nanosleep 300000 309903.32 300000 303980.36 300000 300993.64 > kqueue 300000 300002.77 300000 300019.46 300000 300006.90 > kqueueto 300000 309903.31 300000 303978.10 300000 300996.84 > syscall 300000 4.01 300000 4.04 300000 4.29 Davide asked me in a private followup (long ago) to try the same test with linux running on the same hardware. I finally got around to downloading a linux image for the Raspberry Pi today and did so. The image I used was 2012-12-16-wheezy-raspbian.zip SHA-1 514974a5fcbbbea02151d79a715741c2159d4b0a The test code was the same as last time, except for commenting out the kqueue stuff. Here are the results... 1 79.80 select 1 1077.37 poll 1 74.87 usleep 1 74.83 nanosleep 1 0.00 1 0.00 1 0.87 syscall 300 379.89 select 300 1077.70 poll 300 374.97 usleep 300 374.75 nanosleep 300 0.00 300 0.00 300 0.85 syscall 3000 3085.27 select 3000 3081.32 poll 3000 3081.20 usleep 3000 3081.06 nanosleep 3000 0.00 3000 0.00 3000 0.88 syscall 30000 30093.14 select 30000 30090.79 poll 30000 30090.05 usleep 30000 30088.43 nanosleep 30000 0.00 30000 0.00 30000 0.86 syscall 300000 300351.35 select 300000 300346.16 poll 300000 300097.34 usleep 300000 300097.29 nanosleep 300000 0.00 300000 0.00 300000 0.85 syscall -- Ian From owner-freebsd-arch@FreeBSD.ORG Thu Jan 17 21:17:28 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CC4DD4ED for ; Thu, 17 Jan 2013 21:17:28 +0000 (UTC) (envelope-from stevek@juniper.net) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by mx1.freebsd.org (Postfix) with ESMTP id 8831A16A for ; Thu, 17 Jan 2013 21:17:28 +0000 (UTC) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKUPhqYroa7jwhj56BtNd2/2Etl3YxyoVG@postini.com; Thu, 17 Jan 2013 13:17:28 PST Received: from stevek-ubuntu (172.25.4.212) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.3.213.0; Thu, 17 Jan 2013 13:13:14 -0800 Date: Thu, 17 Jan 2013 16:13:11 -0500 From: Steve Kiernan To: Subject: [JNPR] Proposal to add weak symbols for malloc, realloc, and free to libc Message-ID: <20130117161311.4c15c7c4@stevek-ubuntu> Organization: Juniper Networks Inc. X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.10; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 21:17:28 -0000 When libc was changed to use jemalloc, the weak symbols for malloc, realloc, and free ended up being removed. This makes it a bit difficult for an application to replace (or augment) the malloc implementation. This proposal is to add back the weak symbols similar to how they existed in libc prior to jemalloc introduction. See the following patch for the changes: http://people.freebsd.org/~marcel/Juniper/weak-malloc.diff I'm not sure if the the symbols are in the proper place in the Symbol.map file and would welcome comments. -- Stephen J. Kiernan Juniper Networks, Inc. stevek_at_juniper.net From owner-freebsd-arch@FreeBSD.ORG Thu Jan 17 23:37:02 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8E5137A8 for ; Thu, 17 Jan 2013 23:37:02 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id D18AAD6A for ; Thu, 17 Jan 2013 23:37:01 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.5/8.14.5) with ESMTP id r0HNaubp056453 for ; Thu, 17 Jan 2013 17:36:56 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.5/8.14.5/Submit) id r0HNauPJ056452 for arch@freebsd.org; Thu, 17 Jan 2013 17:36:56 -0600 (CST) (envelope-from brooks) Date: Thu, 17 Jan 2013 17:36:56 -0600 From: Brooks Davis To: arch@freebsd.org Subject: [CFT] switch makefs to use NetBSD mtree Message-ID: <20130117233656.GB55912@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="St7VIuEGZ6dlpu13" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 23:37:02 -0000 --St7VIuEGZ6dlpu13 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable The following patch switches makefs to use NetBSD's mtree's file parsing code which adds support for full pathnames. It also replaces the adhoc compatibility code with libnetbsd. Before applying it you should cd to usr.sbin/makefs and run "rm -rf getid.c compat". Please review or test it out and let me know if it works for you. The patch can also be found at: http://people.freebsd.org/~brooks/patches/makefs-nmtree.diff Thanks Brooks Modify the makefs build to use NetBSD's mtree's parsing code rather than FreeBSD's so that full pathnames are supported in mtree files. Also use libnetbsd instead of the existing compat layer. Sponsored by: DARPA, AFRL Before applying this patch run: rm -rf getid.c compat Index: walk.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- walk.c (revision 245563) +++ walk.c (working copy) @@ -305,7 +305,7 @@ if ((fp =3D fopen(specfile, "r")) =3D=3D NULL) err(1, "Can't open `%s'", specfile); TIMER_START(start); - root =3D mtree_readspec(fp); + root =3D spec(fp); TIMER_RESULTS(start, "spec"); if (fclose(fp) =3D=3D EOF) err(1, "Can't close `%s'", specfile); @@ -321,33 +321,6 @@ =20 } =20 -static u_int -nodetoino(u_int type) -{ - - switch (type) { - case F_BLOCK: - return S_IFBLK; - case F_CHAR: - return S_IFCHR; - case F_DIR: - return S_IFDIR; - case F_FIFO: - return S_IFIFO; - case F_FILE: - return S_IFREG; - case F_LINK: - return S_IFLNK; - case F_SOCK: - return S_IFSOCK; - default: - printf("unknown type %d", type); - abort(); - } - /* NOTREACHED */ -} - - static void apply_specdir(const char *dir, NODE *specnode, fsnode *dirnode, int specon= ly) { Index: makefs.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- makefs.h (revision 245563) +++ makefs.h (working copy) @@ -279,22 +279,4 @@ struct fs; void ffs_fragacct_swap(struct fs *, int, int32_t [], int, int); =20 -/* - * Declarations for compat routines. - */ -long long strsuftoll(const char *, const char *, long long, long long); -long long strsuftollx(const char *, const char *, - long long, long long, char *, size_t); - -struct passwd; -int uid_from_user(const char *, uid_t *); -int pwcache_userdb(int (*)(int), void (*)(void), - struct passwd * (*)(const char *), struct passwd * (*)(uid_= t)); -struct group; -int gid_from_group(const char *, gid_t *); -int pwcache_groupdb(int (*)(int), void (*)(void), - struct group * (*)(const char *), struct group * (*)(gid_t)= ); - -int setup_getid(const char *dir); - #endif /* _MAKEFS_H */ Index: Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- Makefile (revision 245563) +++ Makefile (working copy) @@ -5,7 +5,6 @@ CFLAGS+=3D-I${.CURDIR} =20 SRCS=3D cd9660.c ffs.c \ - getid.c \ makefs.c \ mtree.c \ walk.c @@ -15,19 +14,28 @@ =20 .include "${.CURDIR}/cd9660/Makefile.inc" .include "${.CURDIR}/ffs/Makefile.inc" -.include "${.CURDIR}/compat/Makefile.inc" =20 CFLAGS+=3D-DHAVE_STRUCT_STAT_ST_FLAGS=3D1 CFLAGS+=3D-DHAVE_STRUCT_STAT_ST_GEN=3D1 =20 -.PATH: ${.CURDIR}/../mtree -CFLAGS+=3D-I${.CURDIR}/../mtree -SRCS+=3D misc.c spec.c +.PATH: ${.CURDIR}/../../contrib/mtree +CFLAGS+=3D-I${.CURDIR}/../../contrib/mtree +SRCS+=3D getid.c misc.c spec.c =20 +.PATH: ${.CURDIR}/../../contrib/mknod +CFLAGS+=3D-I${.CURDIR}/../../contrib/mknod +SRCS+=3D pack_dev.c + .PATH: ${.CURDIR}/../../sys/ufs/ffs SRCS+=3D ffs_tables.c =20 -DPADD=3D ${LIBSBUF} -LDADD=3D -lsbuf +CFLAGS+=3D -I${.CURDIR}/../../lib/libnetbsd +LIBNETBSDDIR=3D ${.OBJDIR}/../../lib/libnetbsd +LIBNETBSD=3D ${LIBNETBSDDIR}/libnetbsd.a +DPADD+=3D ${LIBNETBSD} +LDADD+=3D ${LIBNETBSD} =20 +DPADD+=3D ${LIBSBUF} ${LIBUTIL} +LDADD+=3D -lsbuf -lutil + .include --St7VIuEGZ6dlpu13 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFQ+IsYXY6L6fI4GtQRAiK3AKC310eWc9sUkuLz6HiaJ0DU2yPLIACfQimL joZ+EApTT8kqBqK+KO9vV/Q= =YWqL -----END PGP SIGNATURE----- --St7VIuEGZ6dlpu13-- From owner-freebsd-arch@FreeBSD.ORG Thu Jan 17 23:47:46 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3BCDA9E9 for ; Thu, 17 Jan 2013 23:47:46 +0000 (UTC) (envelope-from jasone@canonware.com) Received: from canonware.com (canonware.com [204.109.63.53]) by mx1.freebsd.org (Postfix) with ESMTP id 0A84FDD4 for ; Thu, 17 Jan 2013 23:47:45 +0000 (UTC) Received: from jemac.thefacebook.com (unknown [173.252.71.7]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by canonware.com (Postfix) with ESMTPSA id A3D9E286E5; Thu, 17 Jan 2013 15:42:20 -0800 (PST) Subject: Re: [JNPR] Proposal to add weak symbols for malloc, realloc, and free to libc Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Jason Evans In-Reply-To: <20130117161311.4c15c7c4@stevek-ubuntu> Date: Thu, 17 Jan 2013 15:42:19 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130117161311.4c15c7c4@stevek-ubuntu> To: Steve Kiernan X-Mailer: Apple Mail (2.1283) Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 23:47:46 -0000 On Jan 17, 2013, at 1:13 PM, Steve Kiernan wrote: > When libc was changed to use jemalloc, the weak symbols for malloc, = realloc, and free ended up being removed. > This makes it a bit difficult for an application to replace (or = augment) the malloc implementation. >=20 > This proposal is to add back the weak symbols similar to how they = existed in libc prior to jemalloc introduction. >=20 > See the following patch for the changes: > http://people.freebsd.org/~marcel/Juniper/weak-malloc.diff >=20 > I'm not sure if the the symbols are in the proper place in the = Symbol.map file and would welcome comments. What about calloc(), posix_memalign(), and malloc_usable_size()? = Similarly, I think the *allocm() functions in -current may need the same = treatment. Thanks, Jason= From owner-freebsd-arch@FreeBSD.ORG Thu Jan 17 23:48:41 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CAFD1A96 for ; Thu, 17 Jan 2013 23:48:41 +0000 (UTC) (envelope-from stevek@juniper.net) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by mx1.freebsd.org (Postfix) with ESMTP id CE865DDB for ; Thu, 17 Jan 2013 23:48:40 +0000 (UTC) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKUPiN2Iwj7fVy2suCJV/PsevGCClV6ROh@postini.com; Thu, 17 Jan 2013 15:48:41 PST Received: from stevek-ubuntu (172.25.4.212) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.3.213.0; Thu, 17 Jan 2013 15:46:57 -0800 Date: Thu, 17 Jan 2013 18:46:54 -0500 From: Steve Kiernan To: Jason Evans Subject: Re: [JNPR] Proposal to add weak symbols for malloc, realloc, and free to libc Message-ID: <20130117184654.06f8e330@stevek-ubuntu> In-Reply-To: References: <20130117161311.4c15c7c4@stevek-ubuntu> Organization: Juniper Networks Inc. X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.10; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 23:48:41 -0000 On Thu, 17 Jan 2013 15:42:19 -0800 Jason Evans wrote: > On Jan 17, 2013, at 1:13 PM, Steve Kiernan wrote: > > When libc was changed to use jemalloc, the weak symbols for malloc, realloc, and free ended up being removed. > > This makes it a bit difficult for an application to replace (or augment) the malloc implementation. > > > > This proposal is to add back the weak symbols similar to how they existed in libc prior to jemalloc introduction. > > > > See the following patch for the changes: > > http://people.freebsd.org/~marcel/Juniper/weak-malloc.diff > > > > I'm not sure if the the symbols are in the proper place in the Symbol.map file and would welcome comments. > > What about calloc(), posix_memalign(), and malloc_usable_size()? Similarly, I think the *allocm() functions in -current may need the same treatment. I think you are correct and those would probably be necessary, as well, yes. It looked like previously, calloc was not made weak because it was implemented in terms of malloc, but since that is not the case in jemalloc, it will need to be addressed. I'll update the patch. -- Stephen J. Kiernan Juniper Networks, Inc. stevek_at_juniper.net From owner-freebsd-arch@FreeBSD.ORG Fri Jan 18 04:09:42 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 261B8D63 for ; Fri, 18 Jan 2013 04:09:42 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id BDAF7A89 for ; Fri, 18 Jan 2013 04:09:41 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r0I49XGp055208; Fri, 18 Jan 2013 06:09:33 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r0I49XGp055208 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r0I49XJk055207; Fri, 18 Jan 2013 06:09:33 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 18 Jan 2013 06:09:33 +0200 From: Konstantin Belousov To: Steve Kiernan Subject: Re: [JNPR] Proposal to add weak symbols for malloc, realloc, and free to libc Message-ID: <20130118040933.GU2522@kib.kiev.ua> References: <20130117161311.4c15c7c4@stevek-ubuntu> <20130117184654.06f8e330@stevek-ubuntu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CYcXvPfqKSDi0QhV" Content-Disposition: inline In-Reply-To: <20130117184654.06f8e330@stevek-ubuntu> User-Agent: Mutt/1.5.21 (2010-09-15) 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 version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Jason Evans , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 04:09:42 -0000 --CYcXvPfqKSDi0QhV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 17, 2013 at 06:46:54PM -0500, Steve Kiernan wrote: > On Thu, 17 Jan 2013 15:42:19 -0800 > Jason Evans wrote: >=20 > > On Jan 17, 2013, at 1:13 PM, Steve Kiernan wrote: > > > When libc was changed to use jemalloc, the weak symbols for malloc, r= ealloc, and free ended up being removed. > > > This makes it a bit difficult for an application to replace (or augme= nt) the malloc implementation. > > >=20 > > > This proposal is to add back the weak symbols similar to how they exi= sted in libc prior to jemalloc introduction. > > >=20 > > > See the following patch for the changes: > > > http://people.freebsd.org/~marcel/Juniper/weak-malloc.diff > > >=20 > > > I'm not sure if the the symbols are in the proper place in the Symbol= =2Emap file and would welcome comments. > >=20 > > What about calloc(), posix_memalign(), and malloc_usable_size()? Simil= arly, I think the *allocm() functions in -current may need the same treatme= nt. >=20 > I think you are correct and those would probably be necessary, as well, y= es. >=20 > It looked like previously, calloc was not made weak because it was implem= ented in terms of malloc, but since that is not the case in jemalloc, it wi= ll need to be addressed. >=20 > I'll update the patch. New symbols should be added to the current version, which is FBSD_1.3 for the 10.0. That said, what are the difficulties you experiencing with the malloc interposing ? According to the normal ELF symbol lookup rules, the definitions from any object which is loaded before libc overrides the libc symbols. --CYcXvPfqKSDi0QhV Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQ+Mr8AAoJEJDCuSvBvK1BwJoP/i4KWKy869fJT9PMYUr62msL liKfv9BbDWkY258wTg/TScBNDV7GLvdYtyD58UsfcYoGLN+YKN6Ilf8FHzxj0lKu N62nobUUKELI3TbvacpxgZsy6aC1hlG1an1O4zZFgZk/dLsXhTQY4gX2gIVuBjPY t34v5pDUJrsjDzGv1NoSpWSfLbfjwPOu4Vf6bHlYa/5VIXrSCTEdqtvQmbDtb7B7 svBmwKpr2t1Nx/hG6de9Ro6V8uJMDbQvNt9qFtjMBffdHLLb4JN0cvMzje3R0W89 2UiWAgNDcvYwAPi1/6XUBOkcNR0GNGf2F8gDgdRQrTOmgRAOusEOR9vOn+UXSD0P xw9lWNyBadr5mSZ5gQrxcpMfAQqrBwQrLCk5uxqoEqImigO4/ifHadM/iQlg1DqR AAawBJpRjH8quXVWqAyQt5tmOGJmh+lWfbXSeVHmEo+OT3VKVRNzwCKhrrBGemKC 0oSjGFp7dc5wvzStpTjQQnSIFBbxs9tF2H5bNKeMnmYOs5YyIBrogFXI9UZ53K5F slZvZImvIo7cD32i4z9IqhQki5csRiPj4JBIXUnmZKKGmmse9ubf1VhXFeNRFk7B jIx/bolf8CEwC+0McQJ6HqX2hZaVecqIdkF3hXzzjayXTS3aPk353i8Dkb70NbaD 5K0YbJwPM189NhzHSRbg =5bY2 -----END PGP SIGNATURE----- --CYcXvPfqKSDi0QhV-- From owner-freebsd-arch@FreeBSD.ORG Fri Jan 18 04:31:41 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 84C6032F for ; Fri, 18 Jan 2013 04:31:41 +0000 (UTC) (envelope-from stevek@juniper.net) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by mx1.freebsd.org (Postfix) with ESMTP id 7ADDFB43 for ; Fri, 18 Jan 2013 04:31:39 +0000 (UTC) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKUPjQKvIaaPT/iVZuyceTaBXyTlQ7IEGm@postini.com; Thu, 17 Jan 2013 20:31:41 PST Received: from stevek-ubuntu (172.25.4.212) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.3.213.0; Thu, 17 Jan 2013 20:29:29 -0800 Date: Thu, 17 Jan 2013 23:28:50 -0500 From: Steve Kiernan To: Konstantin Belousov Subject: Re: [JNPR] Proposal to add weak symbols for malloc, realloc, and free to libc Message-ID: <20130117232850.1b69bfc0@stevek-ubuntu> In-Reply-To: <20130118040933.GU2522@kib.kiev.ua> References: <20130117161311.4c15c7c4@stevek-ubuntu> <20130117184654.06f8e330@stevek-ubuntu> <20130118040933.GU2522@kib.kiev.ua> Organization: Juniper Networks Inc. X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.10; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/jHzI=xLs.qM.JOupZjVFARd"; protocol="application/pgp-signature" Cc: Jason Evans , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 04:31:41 -0000 --Sig_/jHzI=xLs.qM.JOupZjVFARd Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Fri, 18 Jan 2013 06:09:33 +0200 Konstantin Belousov wrote: > On Thu, Jan 17, 2013 at 06:46:54PM -0500, Steve Kiernan wrote: > > On Thu, 17 Jan 2013 15:42:19 -0800 > > Jason Evans wrote: > >=20 > > > On Jan 17, 2013, at 1:13 PM, Steve Kiernan wrote: > > > > When libc was changed to use jemalloc, the weak symbols for malloc,= realloc, and free ended up being removed. > > > > This makes it a bit difficult for an application to replace (or aug= ment) the malloc implementation. > > > >=20 > > > > This proposal is to add back the weak symbols similar to how they e= xisted in libc prior to jemalloc introduction. > > > >=20 > > > > See the following patch for the changes: > > > > http://people.freebsd.org/~marcel/Juniper/weak-malloc.diff > > > >=20 > > > > I'm not sure if the the symbols are in the proper place in the Symb= ol.map file and would welcome comments. > > >=20 > > > What about calloc(), posix_memalign(), and malloc_usable_size()? Sim= ilarly, I think the *allocm() functions in -current may need the same treat= ment. > >=20 > > I think you are correct and those would probably be necessary, as well,= yes. > >=20 > > It looked like previously, calloc was not made weak because it was impl= emented in terms of malloc, but since that is not the case in jemalloc, it = will need to be addressed. > >=20 > > I'll update the patch. >=20 > New symbols should be added to the current version, which is FBSD_1.3 > for the 10.0. Okay, great. Thank you for the information. > That said, what are the difficulties you experiencing with the malloc > interposing ? According to the normal ELF symbol lookup rules, the > definitions from any object which is loaded before libc overrides the > libc symbols. The problem is when one want to augment the calls. For example, say you want to do some leak detection or keep track of statistics that the malloc library does not. One would need to still call the original call after replacing the malloc/realloc/free/etc. with their own. Without having the __malloc/__realloc/__free/etc. that _used_ to be in libc, one cannot do so. -- Stephen J. Kiernan Juniper Networks, Inc. stevek_at_juniper.net --Sig_/jHzI=xLs.qM.JOupZjVFARd Content-Type: application/pgp-signature; name="signature.asc" Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlD4z4MACgkQZSuJlLuTi6gMXgCfYq5jgkm/Mymg0BA/WbTmUeZ0 w7cAoLpNsm7xBH8YUZz4bq5nMRR0gayK =vB/z -----END PGP SIGNATURE----- --Sig_/jHzI=xLs.qM.JOupZjVFARd-- From owner-freebsd-arch@FreeBSD.ORG Fri Jan 18 05:29:48 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DD497B08 for ; Fri, 18 Jan 2013 05:29:48 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 3B790DC7 for ; Fri, 18 Jan 2013 05:29:48 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r0I5TdQO073910; Fri, 18 Jan 2013 07:29:39 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r0I5TdQO073910 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r0I5Td1M073909; Fri, 18 Jan 2013 07:29:39 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 18 Jan 2013 07:29:39 +0200 From: Konstantin Belousov To: Steve Kiernan Subject: Re: [JNPR] Proposal to add weak symbols for malloc, realloc, and free to libc Message-ID: <20130118052939.GV2522@kib.kiev.ua> References: <20130117161311.4c15c7c4@stevek-ubuntu> <20130117184654.06f8e330@stevek-ubuntu> <20130118040933.GU2522@kib.kiev.ua> <20130117232850.1b69bfc0@stevek-ubuntu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Pbi2MkfjSbXbI4MN" Content-Disposition: inline In-Reply-To: <20130117232850.1b69bfc0@stevek-ubuntu> User-Agent: Mutt/1.5.21 (2010-09-15) 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 version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Jason Evans , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 05:29:48 -0000 --Pbi2MkfjSbXbI4MN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 17, 2013 at 11:28:50PM -0500, Steve Kiernan wrote: > On Fri, 18 Jan 2013 06:09:33 +0200 > Konstantin Belousov wrote: >=20 > > On Thu, Jan 17, 2013 at 06:46:54PM -0500, Steve Kiernan wrote: > > > On Thu, 17 Jan 2013 15:42:19 -0800 > > > Jason Evans wrote: > > >=20 > > > > On Jan 17, 2013, at 1:13 PM, Steve Kiernan wrote: > > > > > When libc was changed to use jemalloc, the weak symbols for mallo= c, realloc, and free ended up being removed. > > > > > This makes it a bit difficult for an application to replace (or a= ugment) the malloc implementation. > > > > >=20 > > > > > This proposal is to add back the weak symbols similar to how they= existed in libc prior to jemalloc introduction. > > > > >=20 > > > > > See the following patch for the changes: > > > > > http://people.freebsd.org/~marcel/Juniper/weak-malloc.diff > > > > >=20 > > > > > I'm not sure if the the symbols are in the proper place in the Sy= mbol.map file and would welcome comments. > > > >=20 > > > > What about calloc(), posix_memalign(), and malloc_usable_size()? S= imilarly, I think the *allocm() functions in -current may need the same tre= atment. > > >=20 > > > I think you are correct and those would probably be necessary, as wel= l, yes. > > >=20 > > > It looked like previously, calloc was not made weak because it was im= plemented in terms of malloc, but since that is not the case in jemalloc, i= t will need to be addressed. > > >=20 > > > I'll update the patch. > >=20 > > New symbols should be added to the current version, which is FBSD_1.3 > > for the 10.0. >=20 > Okay, great. Thank you for the information. >=20 > > That said, what are the difficulties you experiencing with the malloc > > interposing ? According to the normal ELF symbol lookup rules, the > > definitions from any object which is loaded before libc overrides the > > libc symbols. >=20 > The problem is when one want to augment the calls. For example, say > you want to do some leak detection or keep track of statistics that > the malloc library does not. One would need to still call the original > call after replacing the malloc/realloc/free/etc. with their own. > Without having the __malloc/__realloc/__free/etc. that _used_ to be > in libc, one cannot do so. Well, the standard technique is to do void *libc_handle =3D dlopen("libc.so"); void *(*libc_malloc)(size_t) =3D dlsym(libc_handle, "malloc"); if you know exactly that you want malloc from libc. If you want just any previous interposer for the malloc, then the right technique is to do dlsym(RTLD_NEXT, "malloc") from your malloc wrapper. Still I think that your patch, with additions noted by Jason, is useful. --Pbi2MkfjSbXbI4MN Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQ+N3DAAoJEJDCuSvBvK1BG9oQAJOs5GYCya1p6vp19k3ZgUmn tfC3QNm2olwWsNv4NCUxoJGYPtA2D048UoxaEjgToRcLdwjD2fmj716LkLhQOIei Ugy/HHWmQdaTWZ9gqIh5ZZsneEt5WEGJ0pRmyFLTBco975+SNX4E0RNhJcpirM8t nbqIMNHN26JacWeo+LZFXqgbIOvTJVB9mV2sA+GJ9c96mFC1uwQOk+dOoywnEJ29 WSM+91naZaowEueXSldJu7uORi0Xs1uFeHJZTeKZOsWuW0G2cwSLr4zMszSNvt9o 6/znom+JMWSKQwHZBC+U3FK7VZiEpAWghCb16f7qdXZZ1en0fpX4VtZuERF79C2d 4992Shsyz4D8f7ltuI+z95Pq74Ok8rEphr989CH9xoha5mQZIA1IYAIabuy7Qz7H Eug4yLFhR0VnB1aiD0SzD6BzLvjDc8e4lcAVSqmuw/0jQXb9cpIWzQ1iXEZ65jWu K+oBo1mw1QK6rFYfBPS+fq48qqAnHtGaYQIIPp+xp7HypHIYQGrKt0MzKFYQ0ElQ fX7FJmW4unSfEmoJgJYurLhDuYi2JOD9vdoeLGs/nzcE5lgiPzGdM1kYag8c3Aaz yDI4qCXAqgJV5VMrjObR9tj4TcAxJ6AAO9USZXVIx5NS+DuPi7q1XdXSDnwgIdRZ 9RasAT7Ew/65hIAw2b7C =wUb0 -----END PGP SIGNATURE----- --Pbi2MkfjSbXbI4MN-- From owner-freebsd-arch@FreeBSD.ORG Fri Jan 18 11:11:38 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8FED5180; Fri, 18 Jan 2013 11:11:38 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail27.syd.optusnet.com.au (mail27.syd.optusnet.com.au [211.29.133.168]) by mx1.freebsd.org (Postfix) with ESMTP id B86BCF10; Fri, 18 Jan 2013 11:11:37 +0000 (UTC) Received: from c211-30-173-106.carlnfd1.nsw.optusnet.com.au (c211-30-173-106.carlnfd1.nsw.optusnet.com.au [211.30.173.106]) by mail27.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id r0IBBIhL001611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Jan 2013 22:11:20 +1100 Date: Fri, 18 Jan 2013 22:11:18 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Ian Lepore Subject: Re: [RFC/RFT] calloutng In-Reply-To: <1358432027.32417.213.camel@revolution.hippie.lan> Message-ID: <20130118202123.Y1839@besplex.bde.org> References: <50CCAB99.4040308@FreeBSD.org> <50CE5B54.3050905@FreeBSD.org> <50D03173.9080904@FreeBSD.org> <20121225232126.GA47692@alchemy.franken.de> <50DB4EFE.2020600@FreeBSD.org> <20130106152313.GD26039@alchemy.franken.de> <50EBF921.2000304@FreeBSD.org> <20130113180940.GM26039@alchemy.franken.de> <50F30CAB.3000001@FreeBSD.org> <20130114102118.V1045@besplex.bde.org> <1358432027.32417.213.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=Zty1sKHG c=1 sm=1 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=mUAV9h2nInsA:10 a=_K3Ihd90oorLvW07haYA:9 a=CjuIK1q_8ugA:10 a=TEtd8y5WR3g2ypngnwZWYw==:117 Cc: Davide Italiano , Alexander Motin , freebsd-arch@freebsd.org, FreeBSD Current , Marius Strobl X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 11:11:38 -0000 On Thu, 17 Jan 2013, Ian Lepore wrote: > On Mon, 2013-01-14 at 11:38 +1100, Bruce Evans wrote: >> Er, timecounters are called with a spin mutex held in existing code: >> though it is dangerous to do so, timecounters are called from fast >> interrupt handlers for very timekeeping-critical purposes: >> - to implement the TIOCTIMESTAMP ioctl (except this is broken in >> -current). This was a primitive version of pps timestamping. >> - for pps timestamping. The interrupt handler (which should be a fast >> interrupt handler to minimize latency) calls pps_capture() which >> calls tc_get_timecount() and does other "lock-free" accesses to the >> timecounter state. This still works in -current (at least there is >> still code for it). > > Unfortunately, calling pps_capture() in the primary interrupt context is > no longer an option with the stock pps driver. Ever since the ppbus > rewrite all ppbus children must use threaded handlers. I tried to fix > that a couple different ways, and both ended up with crazy-complex code Hmm, I didn't notice that ppc supported pps (I try not to look at it since it is ugly :-), and don't know of any version of it that uses non-threaded handlers (except in FreeBSD-4 before, where normal interrupt handlers were non-threaded, so ppc had their high latency but not the even higher latency and overheads of threaded handlers). OTOH, my x86 RTC interrupt handler is threaded and supports pps, and I haven't noticed any latency problems with this. It just can't possibly give the < ~1 usec jitter that FreeBSD-[3-4] could give ~15 years ago using a fast interrupt handler (there must be only 1 device using a fast interrupt handler, with this dedicated to pps, else the multiple fast interrupt handlers will give latency much larger than ~1 usec to each other. I don't actually use this for anything except testing whether the RTC can be used for a poor man's pps. > scattered around the ppbus family just to support the rarely-used pps > capture. It would have been easier to do if filter and threaded > interrupt handlers had the same function signature. > > I ended up writting a separate driver that can be used instead of ppc + > ppbus + pps, since anyone who cares about precise pps capture is > unlikely to be sharing the port with a printer or plip device or some > such. Probably all pps handlers should be special. On x86 with reasonable timecounter hardware, say a TSC, it takes about 10 instructions for an entire pps interrupt handler: XintrN: pushl %eax pushl %edx rdtsc # Need some ugliness for EIO here or later. ss:movl %eax,ppscap # Hopefully lock-free via time-domain locking. ss:movl %edx,ppscap+4 popl %edx popl %eax iret After capturing the timecounter hardware value here, you convert it to a pps event at leisure. But since this only happens once per second, it wouldn't be very inefficient to turn the interrupt handler into a slow high-latency one, even a threaded one, to handle the pps event and/or other devices attached to the interrupt. >> OTOH, all drivers that call pps_capture() from their interrupt handler >> then immediately call pps_event(). This has always been very broken, >> and became even more broken with SMPng. pps_event() does many more >> timecounter and pps accesses whose locking is unclear at best, and >> in some configurations it calls hardpps(), which is only locked by >> Giant, despite comments in kern_ntptime.c still saying that it (and >> many other functions in kern_ntptime.c) must be called at splclock() >> or higher. splclock() is of course now null, but the locking >> requirements in kern_ntptime.c haven't changed much. kern_ntptime.c >> always needed to be locked by the equivalent of a spin mutex, which >> is stronger locking than was given by splclock(). pps_event() would >> have to aquire the spin mutex before calling hardpps(), although >> this is bad for fast interrupt handlers. The correct implementation >> is probably to only do the capture part from fast interrupt handlers. > > In my rewritten dedicated pps driver I call pps_capture() from the > filter handler and pps_event() from the threaded handler. I never found That seems right. > any good documentation on the low-level details of this stuff, and there > isn't enough good example code to work from. My hazy memory is that I THere seem to be no good examples. > ended up studying the pps_capture() and pps_event() code enough to infer > that their design intent seems to be to allow you to capture with no > locking and do the event processing later in some sort of deferred or > threaded context. That seems to be the design, but there are no examples of separating the event from the capture. I think the correct locking is: - capture in a fast interrupt handler, into a per-device state that is locked by whatever locks all of the state accessed by the fast interrupt handler - switch to a less critical context later: - lock this step agains reentrance from itself - re-acquire the fast interrupt handler's lock, as strictly necessary to access the state locked by that, and copy it to local state. Release the fast interrupt handler's lock. This locking can probably be skipped since the capture only happens once per second and it is possible to arrange doing this step somewhere in between the captures, but that would be more complicated and fragile. - acquire the lock that protects all the state accessed by pps_event(). This is currently Giant for at least the hardpps() parts. This restricts the contexts that can call pps_capture(). Of course, kern_ntptime.c should use finer locking than Giant, so as to not restrict its callers so much. Its Giant locking is also violated by calling ntp_update_second() from the tc_windup() filter. It's surprising that the races here are so rarely harmful that no one has reported them being lost. Maybe they are only lost on leap seconds synchronized with new moons. >> ... >> The spinlock in the i8254 timecounter certainly breaks some cases. >> For example, suppose the lock is held for a timecounter read from >> normal context. It masks hardware interrupts on the current CPU (except >> in my version). It doesn't mask NMIs or other traps. So if the NMI >> or other trap handler does a timecounter hardware call, there is >> deadlock in at least the !SMP case. In my version, it blocks normal >> interrupts later if they occur, but doesn't block fast interrupts, so >> the pps_capture() call would deadlock if it occurs, like a timecounter >> call from an NMI. I avoid this by not using pps in any fast interrupt >> handler, and by only using the i8254 timecounter for testing. I do >> use pps in a (nonstandard) x86 RTC clock interrupt handler. My clock >> interrupt handlers are all non-fast to avoid this and other locking >> problems. > > Hrm, now you've got me a bit worried about capturing in the primary > context. Not that I have much option, on a 300mhz Geode and similar > wimpy embedded processors there's enough latency on a theaded handler > that the pps signal can be de-asserted by time the handler runs > (precision timing gear often outputs a very narrow pps pulse, 1 - 10uS > isn't uncommon). This reminds me that the old Centronics printer interface has similar timing. This caused "lost" printer interrupts on x86 (due to the 8259 not latching them?), and the polling to recover from this was handled poorly by drivers in 386BSD and Linux. If the hardware does latch things, then there would still be a problem determining if the interrupt is for you if it is shared. In the Centronics interface mapped to x86, the interrupt signal can be polled for, but it is of course hard to see since it is short. > I know I don't have to worry about NMIs on the systems in question, but > I'm not so sure about "other trap handler". There aren't many except machine check and debugger traps on x86. Ones like pagefaults shouldn't occur while holding locks. Bruce From owner-freebsd-arch@FreeBSD.ORG Fri Jan 18 13:05:32 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A5CC6974 for ; Fri, 18 Jan 2013 13:05:32 +0000 (UTC) (envelope-from stevek@juniper.net) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by mx1.freebsd.org (Postfix) with ESMTP id 4B24A76B for ; Fri, 18 Jan 2013 13:05:32 +0000 (UTC) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKUPlIm/k9VHkbsc9AHk6IkvXCBrNhfmGW@postini.com; Fri, 18 Jan 2013 05:05:32 PST Received: from stevek-ubuntu (172.25.4.212) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.3.213.0; Fri, 18 Jan 2013 04:53:31 -0800 Date: Fri, 18 Jan 2013 07:53:21 -0500 From: Steve Kiernan To: Konstantin Belousov Subject: Re: [JNPR] Proposal to add weak symbols for malloc, realloc, and free to libc Message-ID: <20130118075321.5c1ae9ee@stevek-ubuntu> In-Reply-To: <20130118052939.GV2522@kib.kiev.ua> References: <20130117161311.4c15c7c4@stevek-ubuntu> <20130117184654.06f8e330@stevek-ubuntu> <20130118040933.GU2522@kib.kiev.ua> <20130117232850.1b69bfc0@stevek-ubuntu> <20130118052939.GV2522@kib.kiev.ua> Organization: Juniper Networks Inc. X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.10; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/f/FxglD/52jn=PCB4c53jsQ"; protocol="application/pgp-signature" Cc: Jason Evans , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 13:05:32 -0000 --Sig_/f/FxglD/52jn=PCB4c53jsQ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Fri, 18 Jan 2013 07:29:39 +0200 Konstantin Belousov wrote: > On Thu, Jan 17, 2013 at 11:28:50PM -0500, Steve Kiernan wrote: > > On Fri, 18 Jan 2013 06:09:33 +0200 > > Konstantin Belousov wrote: > >=20 > > > That said, what are the difficulties you experiencing with the malloc > > > interposing ? According to the normal ELF symbol lookup rules, the > > > definitions from any object which is loaded before libc overrides the > > > libc symbols. > >=20 > > The problem is when one want to augment the calls. For example, say > > you want to do some leak detection or keep track of statistics that > > the malloc library does not. One would need to still call the original > > call after replacing the malloc/realloc/free/etc. with their own. > > Without having the __malloc/__realloc/__free/etc. that _used_ to be > > in libc, one cannot do so. >=20 > Well, the standard technique is to do > void *libc_handle =3D dlopen("libc.so"); > void *(*libc_malloc)(size_t) =3D dlsym(libc_handle, "malloc"); > if you know exactly that you want malloc from libc. >=20 > If you want just any previous interposer for the malloc, then the right > technique is to do dlsym(RTLD_NEXT, "malloc") from your malloc wrapper. That is only guaranteed to work if you're linking with libc dynamically. If you statically link, that may not necessarily work. Having the weak symbols ensures things will work correctly no matter which linking method one uses. -Steve --Sig_/f/FxglD/52jn=PCB4c53jsQ Content-Type: application/pgp-signature; name="signature.asc" Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlD5RcIACgkQZSuJlLuTi6htmgCePNcIUbEkle0pEgZ3JdZcXWvq td8AoMQt2dJipVxvrB0So2pkR0UwPK/3 =iBHT -----END PGP SIGNATURE----- --Sig_/f/FxglD/52jn=PCB4c53jsQ-- From owner-freebsd-arch@FreeBSD.ORG Sat Jan 19 00:19:43 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F33E87EE for ; Sat, 19 Jan 2013 00:19:42 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id 6980BF8A for ; Sat, 19 Jan 2013 00:19:42 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.5/8.14.5) with ESMTP id r0J0Jbl3067838 for ; Fri, 18 Jan 2013 18:19:37 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.5/8.14.5/Submit) id r0J0JbH0067837 for arch@freebsd.org; Fri, 18 Jan 2013 18:19:37 -0600 (CST) (envelope-from brooks) Date: Fri, 18 Jan 2013 18:19:37 -0600 From: Brooks Davis To: arch@freebsd.org Subject: non-root installworld/distributeworld coming to current soon Message-ID: <20130119001937.GK56576@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2013 00:19:43 -0000 Now that I've merged the required features from NetBSD's install to ours It's time to implement non-root installworld and packaging. The patches found at http://people.freebsd.org/~brooks/patches/noroot accomplish this. I plan to commit them early next week. They are as follows: 00-install.sh.diff Implement the -l option in install.sh to facilitate boostrapping. 01-install_link.diff Replace all known instance of "ln -f" and "ln -fs" with "install -l h" and "install -l s". 02-infodir-644.diff Install the info directory with mode 644 rather than 444 so install-info works when run as non-root. 03-install-U.diff Use install -U in place of install.sh once we've bootstrapped the new install. It will save a few sh invocations and probably speed the build up slightly but I've not bothered to measure. 04-no_root.diff Add support for the -DNO_ROOT and METALOG= variables. Except for one case in the distributeworld path were a layer of indirection is eliminated on the way to calling "make distrib-dirs" in etc and adding variables to a few make invocations, the code leaves the non-NO_ROOT path untouched. Please review or test and provide any feedback you may have. Thanks, Brooks From owner-freebsd-arch@FreeBSD.ORG Sat Jan 19 06:29:17 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 67844261 for ; Sat, 19 Jan 2013 06:29:17 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 35BECDBE for ; Sat, 19 Jan 2013 06:29:17 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (c-67-180-208-218.hsd1.ca.comcast.net [67.180.208.218]) by elvis.mu.org (Postfix) with ESMTPSA id 09BEE1A3C33 for ; Fri, 18 Jan 2013 22:29:10 -0800 (PST) Message-ID: <50FA3D36.4080709@mu.org> Date: Fri, 18 Jan 2013 22:29:10 -0800 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "arch@freebsd.org" Subject: RFC: enhanced watchdog. References: <201301190604.r0J64RbW009298@svn.freebsd.org> In-Reply-To: <201301190604.r0J64RbW009298@svn.freebsd.org> X-Forwarded-Message-Id: <201301190604.r0J64RbW009298@svn.freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2013 06:29:17 -0000 We at iX are trying to enhance the watchdog and we think some of the changes may benefit the community as a whole. Basically we want to make it easy for developers to prototype watchdog scripts in a "test-only" mode that basically logs if the watchdog had failed. I have most of the code done, but could really use help on two things: 1) review 2) suggestion for inserting the warning messages from the userland watchdogd into the kernel message buffer. 3) suggestion for logging/warning of pending death. In detail: 1) The reason for review should be obvious, we want to make sure that this works for everyone. 2) The reason for inserting messages into the kernel log is because that is the easiest place for us to recover the diagnostics when we do have a crash due to watchdog. Maybe there is a smarter thing to do? 3) What is a good way to warn of impeding death? I was thinking of just another thread in the process that would be signalled before the watchdog script was run and would log when the timer is about to expire or based on a configurable threshold. Finally, there is some thought about adding a kernel daemon to the watchdog facility that would allow us to strobe watchdogs with low max values while our userland watchdog was polling the system. Why??? Well because the ICH driver has a max timeout of ~2 minutes. We really want to be able to leverage this watchdog, but also go higher than this. The way to do this is to drive the system almost like a step up electrical relay. The way this works is that you have a thread who's logic is as follows: short_wd_strober(){ for ( ;; ) { /* wait to be signalled or a timeout. */ error = msleep(&short_wd, &short_mtx, 0, "shrtwd", hz * 2); /* we got signalled, reset the last long_strobe so we continue to "relay" the strobe */ if (error == 0) { long_strobe = currsec; } /* if the time since our last signal is less than long_strobe_interval then strobe the watchdog otherwise just loop.. hopefully we get a signal soon */ if (currsec - long_strobe < long_strobe_interval){ strobe_watchdogs(); } else { if (currsec - long_strobe > long_strobe_warning) log("...something about not seeing a long strobe in a while"); } } Another ioctl can be used to poke this thread and effectively signal the &short_wd wait channel. (note the primitives will be fixed here, I _know_ we need flags or perhaps a cv would be better). -Alfred -------- Original Message -------- Subject: svn commit: r245658 - user/alfred/ewatchdog/usr.sbin/watchdogd Date: Sat, 19 Jan 2013 06:04:27 +0000 (UTC) From: Alfred Perlstein To: src-committers@freebsd.org, svn-src-user@freebsd.org Author: alfred Date: Sat Jan 19 06:04:26 2013 New Revision: 245658 URL: http://svnweb.freebsd.org/changeset/base/245658 Log: Add code to watchdog to time the watchdog command program, carp when the program takes too long. The purpose of this is to allow system integrators to tune their watchdogs and get advanced notice if they are behaving poorly. The following facilities are added: - Warn if the watchdog program takes too long. - Disable activation of the system watchdog so that one can test the watchdogd script without potentially rebooting the system. - Ability to log to syslog when scripts begin to timeout. The following changes are included: - When told to measure time, do not unconditionally nap for 'sleep' seconds, instead adjust the naptime by the elapsed time so as not to trigger the watchdog. Example: /usr/trees/head/usr.sbin/watchdogd # ./watchdogd -d -n -w -e "sleep 1" watchdogd: mlockall failed: Cannot allocate memory watchdogd: Watchdog program: 'sleep 1' took too long: 1.010894 seconds >= 1 seconds threshhold watchdogd: Watchdog program: 'sleep 1' took too long: 1.010636 seconds >= 1 seconds threshhold watchdogd: Watchdog program: 'sleep 1' took too long: 1.010700 seconds >= 1 seconds threshhold ^C /usr/trees/head/usr.sbin/watchdogd # ./watchdogd -d -n -w -e "sleep 0.9" watchdogd: mlockall failed: Cannot allocate memory ... doesn't complain ... Modified: user/alfred/ewatchdog/usr.sbin/watchdogd/watchdogd.8 user/alfred/ewatchdog/usr.sbin/watchdogd/watchdogd.c Modified: user/alfred/ewatchdog/usr.sbin/watchdogd/watchdogd.8 ============================================================================== --- user/alfred/ewatchdog/usr.sbin/watchdogd/watchdogd.8 Sat Jan 19 05:55:18 2013 (r245657) +++ user/alfred/ewatchdog/usr.sbin/watchdogd/watchdogd.8 Sat Jan 19 06:04:26 2013 (r245658) @@ -33,11 +33,12 @@ .Nd watchdog daemon .Sh SYNOPSIS .Nm -.Op Fl d +.Op Fl dnw .Op Fl e Ar cmd .Op Fl I Ar file .Op Fl s Ar sleep .Op Fl t Ar timeout +.Op Fl T Ar script_timeout .Sh DESCRIPTION The .Nm @@ -62,6 +63,13 @@ is not specified, the daemon will perfor check instead. .Pp The +.Fl n +argument 'dry-run' will cause watchdog not to arm the system watchdog and +instead only run the watchdog function and report on failures. +This is useful for developing new watchdogd scripts as the system will not +reboot if there are problems with the script. +.Pp +The .Fl s Ar sleep argument can be used to control the sleep period between each execution of the check and defaults to one second. @@ -78,6 +86,16 @@ If this occurs, will no longer execute and thus the kernel's watchdog routines will take action after a configurable timeout. .Pp +The +.Fl T Ar script_timeout +specifies the threshold (in seconds) at which the watchdogd will complain +that its script has run for too long. +If unset +.Ar script_timeout +defaults to the value specified by the +.Fl s Ar sleep +option. +.Pp Upon receiving the .Dv SIGTERM or @@ -100,6 +118,11 @@ Do not fork. When this option is specified, .Nm will not fork into the background at startup. +.Pp +.It Fl w +Complain when the watchdog script takes too long. +This flag will cause watchdogd to complain when the amount of time to +execute the watchdog script exceeds the threshold of 'sleep' option. .El .Sh FILES .Bl -tag -width ".Pa /var/run/watchdogd.pid" -compact Modified: user/alfred/ewatchdog/usr.sbin/watchdogd/watchdogd.c ============================================================================== --- user/alfred/ewatchdog/usr.sbin/watchdogd/watchdogd.c Sat Jan 19 05:55:18 2013 (r245657) +++ user/alfred/ewatchdog/usr.sbin/watchdogd/watchdogd.c Sat Jan 19 06:04:26 2013 (r245658) @@ -50,6 +50,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include static void parseargs(int, char *[]); @@ -66,8 +67,14 @@ static const char *pidfile = _PATH_VARRU static u_int timeout = WD_TO_16SEC; static u_int passive = 0; static int is_daemon = 0; +static int is_dry_run = 0; /* do not arm the watchdog, only + report on timing of the watch + program */ +static int do_timedog = 0; +static int do_syslog = 0; static int fd = -1; static int nap = 1; +static int carp_thresh_seconds = -1; static char *test_cmd = NULL; /* @@ -85,12 +92,18 @@ main(int argc, char *argv[]) parseargs(argc, argv); + if (do_syslog) { + openlog("watchdogd", LOG_CONS|LOG_NDELAY|LOG_PERROR, + LOG_DAEMON); + + } + rtp.type = RTP_PRIO_REALTIME; rtp.prio = 0; if (rtprio(RTP_SET, 0, &rtp) == -1) err(EX_OSERR, "rtprio"); - if (watchdog_init() == -1) + if (!is_dry_run && watchdog_init() == -1) errx(EX_SOFTWARE, "unable to initialize watchdog"); if (is_daemon) { @@ -156,6 +169,9 @@ static int watchdog_init(void) { + if (is_dry_run) + return 0; + fd = open("/dev/" _PATH_WATCHDOG, O_RDWR); if (fd >= 0) return (0); @@ -164,26 +180,98 @@ watchdog_init(void) } /* + * If we are doing timing, then get the time. + */ +static int +watchdog_getuptime(struct timespec *tp) +{ + int error; + + if (!do_timedog) + return 0; + + error = clock_gettime(CLOCK_UPTIME_FAST, tp); + if (error) + warn("clock_gettime"); + return (error); +} + +static long +watchdog_check_dogfunction_time(struct timespec *tp_start, + struct timespec *tp_end) +{ + struct timeval tv_start, tv_end, tv; + const char *cmd_prefix, *cmd; + int sec; + + if (!do_timedog) + return (0); + + TIMESPEC_TO_TIMEVAL(&tv_start, tp_start); + TIMESPEC_TO_TIMEVAL(&tv_end, tp_end); + timersub(&tv_end, &tv_start, &tv); + sec = tv.tv_sec; + if (sec < carp_thresh_seconds) + return (sec); + + if (test_cmd) { + cmd_prefix = "Watchdog program"; + cmd = test_cmd; + } else { + cmd_prefix = "Watchdog operation"; + cmd = "stat(\"/etc\", &sb)"; + } + if (do_syslog) + syslog(LOG_CRIT, "%s: '%s' took too long: " + "%d.%06ld seconds >= %d seconds threshhold", + cmd_prefix, cmd, sec, (long)tv.tv_usec, + carp_thresh_seconds); + warnx("%s: '%s' took too long: " + "%d.%06ld seconds >= %d seconds threshhold", + cmd_prefix, cmd, sec, (long)tv.tv_usec, carp_thresh_seconds); + return (sec); +} + + +/* * Main program loop which is iterated every second. */ static void watchdog_loop(void) { + struct timespec ts_start, ts_end; struct stat sb; - int failed; + long waited; + int error, failed; while (end_program != 2) { failed = 0; + error = watchdog_getuptime(&ts_start); + if (error) { + end_program = 1; + goto try_end; + } + if (test_cmd != NULL) failed = system(test_cmd); else failed = stat("/etc", &sb); + error = watchdog_getuptime(&ts_end); + if (error) { + end_program = 1; + goto try_end; + } + + waited = watchdog_check_dogfunction_time(&ts_start, &ts_end); + if (failed == 0) watchdog_patpat(timeout|WD_ACTIVE); - sleep(nap); + if (nap - waited > 0) + sleep(nap - waited); +try_end: if (end_program != 0) { if (watchdog_onoff(0) == 0) { end_program = 2; @@ -203,6 +291,9 @@ static int watchdog_patpat(u_int t) { + if (is_dry_run) + return 0; + return ioctl(fd, WDIOCPATPAT, &t); } @@ -214,6 +305,10 @@ static int watchdog_onoff(int onoff) { + /* fake successful watchdog op if a dry run */ + if (is_dry_run) + return 0; + if (onoff) return watchdog_patpat((timeout|WD_ACTIVE)); else @@ -227,12 +322,26 @@ static void usage(void) { if (is_daemon) - fprintf(stderr, "usage: watchdogd [-d] [-e cmd] [-I file] [-s sleep] [-t timeout]\n"); + fprintf(stderr, "usage: watchdogd [-dnw] [-e cmd] [-I file] [-s sleep] [-t timeout] [-T script_timeout]\n"); else fprintf(stderr, "usage: watchdog [-d] [-t timeout]\n"); exit(EX_USAGE); } +static long +fetchtimeout(int opt, const char *myoptarg) +{ + char *p; + long rv; + + p = NULL; + errno = 0; + rv = strtol(myoptarg, &p, 0); + if ((p != NULL && *p != '\0') || errno != 0) + errx(EX_USAGE, "-%c argument is not a number", opt); + return (rv); +} + /* * Handle the few command line arguments supported. */ @@ -247,7 +356,7 @@ parseargs(int argc, char *argv[]) if (argv[0][c - 1] == 'd') is_daemon = 1; while ((c = getopt(argc, argv, - is_daemon ? "I:de:s:t:?" : "dt:?")) != -1) { + is_daemon ? "I:de:ns:t:ST:w?" : "dt:?")) != -1) { switch (c) { case 'I': pidfile = optarg; @@ -258,17 +367,19 @@ parseargs(int argc, char *argv[]) case 'e': test_cmd = strdup(optarg); break; + case 'n': + is_dry_run = 1; + break; #ifdef notyet case 'p': passive = 1; break; #endif case 's': - p = NULL; - errno = 0; - nap = strtol(optarg, &p, 0); - if ((p != NULL && *p != '\0') || errno != 0) - errx(EX_USAGE, "-s argument is not a number"); + nap = fetchtimeout(c, optarg); + break; + case 'S': + do_syslog = 1; break; case 't': p = NULL; @@ -286,12 +397,22 @@ parseargs(int argc, char *argv[]) printf("Timeout is 2^%d nanoseconds\n", timeout); break; + case 'T': + carp_thresh_seconds = fetchtimeout(c, optarg); + break; + case 'w': + do_timedog = 1; + break; case '?': default: usage(); /* NOTREACHED */ } } + + if (carp_thresh_seconds == -1) + carp_thresh_seconds = nap; + if (argc != optind) errx(EX_USAGE, "extra arguments."); if (is_daemon && timeout < WD_TO_1SEC) From owner-freebsd-arch@FreeBSD.ORG Sat Jan 19 14:21:21 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D260EA37 for ; Sat, 19 Jan 2013 14:21:21 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 95D2EDEE for ; Sat, 19 Jan 2013 14:21:21 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 83D618A51E; Sat, 19 Jan 2013 14:21:20 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id r0JELKBM001862; Sat, 19 Jan 2013 14:21:20 GMT (envelope-from phk@phk.freebsd.dk) To: Alfred Perlstein Subject: Re: RFC: enhanced watchdog. In-reply-to: <50FA3D36.4080709@mu.org> From: "Poul-Henning Kamp" References: <201301190604.r0J64RbW009298@svn.freebsd.org> <50FA3D36.4080709@mu.org> Date: Sat, 19 Jan 2013 14:21:20 +0000 Message-ID: <1861.1358605280@critter.freebsd.dk> Cc: "arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2013 14:21:21 -0000 Content-Type: text/plain; charset=ISO-8859-1 -------- In message <50FA3D36.4080709@mu.org>, Alfred Perlstein writes: >We at iX are trying to enhance the watchdog and we think some of the >changes may benefit the community as a whole. The initial watchdog support was generalized from only two examples and therefore quite crude. I think your proposed improvements make good sense. I will generally warn you not to make things too complex though, it's important that the watchdog subsystem does not become a cause of failure on its own. Having a kernel thread which tries to get attention some delta-T before the hardware watchdog is supposed to kick in, also sounds like a good idea, but its information is going to be quite unreliable. One wish I have heard, was to be able to use multiple WD's separately, the current API sort of treats them as a redundant pool. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Sat Jan 19 14:59:41 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7498CE1F for ; Sat, 19 Jan 2013 14:59:41 +0000 (UTC) (envelope-from chagin.dmitry@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id F41CCECE for ; Sat, 19 Jan 2013 14:59:40 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id gg6so2783833lbb.13 for ; Sat, 19 Jan 2013 06:59:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=ikVScQC5hMEmA81UC5YYytSoX6tK2E2/7b0PaFWBWvQ=; b=JNCFehNzVof153+cDpWhSSyo8akkpZ11TsCxKgAJ3oSH289Cc0X1XuonbEl8UnGgb3 NxOXOVvyUVdnW9Qw8vydMeef9bhfdYrsKm9rvyEYSYMKYxnBL2N2df8eAMTAG08RKZ7J z2bKNxj3Zd58HMaQwtlx5CEGCeDITJPIe0JTJOu4uOFjUA7vcMuqmuyYCG40LLym45hn bUXf46NfnSFEwHrRn9hvmicRx+Z/KLa8EvW3HVIu29FsKo0+hPDeH+V39c0pIazc1X2s prGBoaSqQGr+4Hg2HC4hyygkxuktHTtbfLtVimoGReWfbPmEXRs6ckOV0KMpl/TaKmi2 GUYQ== X-Received: by 10.112.17.129 with SMTP id o1mr5251571lbd.54.1358607572685; Sat, 19 Jan 2013 06:59:32 -0800 (PST) Received: from dchagin.static.corbina.net (dchagin.static.corbina.ru. [78.107.232.239]) by mx.google.com with ESMTPS id hq9sm3187487lab.8.2013.01.19.06.59.31 (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 19 Jan 2013 06:59:31 -0800 (PST) Received: from dchagin.static.corbina.net (localhost [127.0.0.1]) by dchagin.static.corbina.net (8.14.6/8.14.6) with ESMTP id r0JExTjo023241; Sat, 19 Jan 2013 18:59:29 +0400 (MSK) (envelope-from dchagin@dchagin.static.corbina.net) Received: (from dchagin@localhost) by dchagin.static.corbina.net (8.14.6/8.14.6/Submit) id r0JExTCG023240; Sat, 19 Jan 2013 18:59:29 +0400 (MSK) (envelope-from dchagin) Date: Sat, 19 Jan 2013 18:59:29 +0400 From: Chagin Dmitry To: d@delphij.net Subject: Re: RFC: futimens(2) and utimensat(2) Message-ID: <20130119145929.GA23230@dchagin.static.corbina.net> References: <4F4DC876.3010809@delphij.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="82I3+IH0IqGh5yIs" Content-Disposition: inline In-Reply-To: <4F4DC876.3010809@delphij.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2013 14:59:41 -0000 --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 28, 2012 at 10:40:54PM -0800, Xin Li wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 >=20 > Hi, >=20 > These are required by IEEE Std 1003.1-2008. Patchset at: >=20 > http://people.freebsd.org/~delphij/for_review/utimens.diff >=20 > Cheers, > - --=20 > Xin LI https://www.delphij.net/ > FreeBSD - The Power to Serve! Live free or die > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.18 (FreeBSD) Hi Xin, Do you plan to commit this? --=20 Have fun! chd --82I3+IH0IqGh5yIs Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlD6tNEACgkQ0t2Tb3OO/O2ZVACfRI3lnyLAqI7uDYp3/rAkkct3 7j4AoLWdxIPL02Eh7wZWDUj/tKb9lgLR =0EPh -----END PGP SIGNATURE----- --82I3+IH0IqGh5yIs-- From owner-freebsd-arch@FreeBSD.ORG Sat Jan 19 17:36:58 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9DB86986 for ; Sat, 19 Jan 2013 17:36:58 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 7373A9AF for ; Sat, 19 Jan 2013 17:36:58 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (c-67-180-208-218.hsd1.ca.comcast.net [67.180.208.218]) by elvis.mu.org (Postfix) with ESMTPSA id 715401A3C24; Sat, 19 Jan 2013 09:36:55 -0800 (PST) Message-ID: <50FAD9B6.6050303@mu.org> Date: Sat, 19 Jan 2013 09:36:54 -0800 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Poul-Henning Kamp Subject: Re: RFC: enhanced watchdog. References: <201301190604.r0J64RbW009298@svn.freebsd.org> <50FA3D36.4080709@mu.org> <1861.1358605280@critter.freebsd.dk> In-Reply-To: <1861.1358605280@critter.freebsd.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2013 17:36:58 -0000 On 1/19/13 6:21 AM, Poul-Henning Kamp wrote: > Content-Type: text/plain; charset=ISO-8859-1 > -------- > In message <50FA3D36.4080709@mu.org>, Alfred Perlstein writes: > >> We at iX are trying to enhance the watchdog and we think some of the >> changes may benefit the community as a whole. > The initial watchdog support was generalized from only two examples > and therefore quite crude. > > I think your proposed improvements make good sense. Thanks for the kind words. > > I will generally warn you not to make things too complex though, > it's important that the watchdog subsystem does not become a > cause of failure on its own. Agreed. I get very nervous when I see rtprio calls in any program and will certainly tread very carefully here. > > Having a kernel thread which tries to get attention some delta-T > before the hardware watchdog is supposed to kick in, also sounds > like a good idea, but its information is going to be quite unreliable. > > One wish I have heard, was to be able to use multiple WD's separately, > the current API sort of treats them as a redundant pool. Yes, this also is interesting to me. I started sketching up some ways to do this, but then realized I was probably reinventing the wheel. Can someone refer me to examples of a system I could crib from instead of starting from scratch? -Alfred From owner-freebsd-arch@FreeBSD.ORG Sat Jan 19 18:45:54 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 06E0D42A for ; Sat, 19 Jan 2013 18:45:54 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (unknown [IPv6:2001:610:1108:5012::107]) by mx1.freebsd.org (Postfix) with ESMTP id C52EFC16 for ; Sat, 19 Jan 2013 18:45:53 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 75327120207; Sat, 19 Jan 2013 19:45:39 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id 575E62848C; Sat, 19 Jan 2013 19:45:39 +0100 (CET) Date: Sat, 19 Jan 2013 19:45:39 +0100 From: Jilles Tjoelker To: Chagin Dmitry Subject: Re: RFC: futimens(2) and utimensat(2) Message-ID: <20130119184539.GA78815@stack.nl> References: <4F4DC876.3010809@delphij.net> <20130119145929.GA23230@dchagin.static.corbina.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130119145929.GA23230@dchagin.static.corbina.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: pluknet@frteebsd.org, d@delphij.net, freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2013 18:45:54 -0000 On Sat, Jan 19, 2013 at 06:59:29PM +0400, Chagin Dmitry wrote: > On Tue, Feb 28, 2012 at 10:40:54PM -0800, Xin Li wrote: > > These are required by IEEE Std 1003.1-2008. Patchset at: > > http://people.freebsd.org/~delphij/for_review/utimens.diff > Hi Xin, > Do you plan to commit this? I would like to see a good implementation of futimens(2) and utimensat(2) in 10.0. From what I remember, pluknet@'s patch was closer to that than delphij@'s patch. (For example, a timespec array with both values UTIME_NOW should require the same permissions as a NULL timespec array.) I wrote a man page: http://www.stack.nl/~jilles/unix/utimensat.2 I think it is best to have a separate man page and not stuff the new calls into the utimes/lutimes/futimes/futimesat man page, which would end up rather confusing. -- Jilles Tjoelker