From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 14 01:59:56 2015 Return-Path: Delivered-To: freebsd-hackers@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C8ED7CB9; Sun, 14 Jun 2015 01:59:56 +0000 (UTC) (envelope-from erichsfreebsdlist@alogt.com) Received: from alogt.com (alogt.com [69.36.191.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A4DE8280; Sun, 14 Jun 2015 01:59:56 +0000 (UTC) (envelope-from erichsfreebsdlist@alogt.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=AyC/SFwruEWP3Gurwe/qr3PTl5RjTjrmYSY1LYZle1Q=; b=psYYYbw+T1IthvgGa+2jJeyHSo62hzQinjJg8er77tb8Uj9ESWEsxN6x5nBIoRQssPyst4XDuC+dmmRahTeSO48xlZyOkqhTPoIKdqxyHIPrPR0lEwo4u3Rg2Bt16isYwO4gvLAt23B6HP9mcmisvTxijEYZc/ul6QbZ3qiynJs=; Received: from [114.121.135.137] (port=21877 helo=B85M-HD3-0.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.85) (envelope-from ) id 1Z3xDA-001vzo-Ei; Sat, 13 Jun 2015 19:59:49 -0600 Date: Sun, 14 Jun 2015 09:59:41 +0800 From: Erich Dollansky To: Richard Yao Cc: Hans Petter Selasky , Ian Lepore , "freebsd-hackers@freebsd.org" Subject: Re: allow ffs & co. a binary search Message-ID: <20150614095941.667035a6@B85M-HD3-0.alogt.com> In-Reply-To: <557ADF46.6030004@gentoo.org> References: <20150607081315.7c0f09fb@B85M-HD3-0.alogt.com> <5579A016.4040800@gentoo.org> <1434034373.1415.3.camel@freebsd.org> <5579A235.80609@gentoo.org> <557A3CF3.3050603@selasky.org> <557AD8B0.6000600@gentoo.org> <557ADF46.6030004@gentoo.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2015 01:59:56 -0000 Hi All, what should we do now? There are several approaches now on the table. I would implement this use the built-in methods of the compiler when available and use the Stanford functions in other cases and and keep the current solution as a fall back I would use macros to determine which solution should be used. What are your thoughts? Erich On Fri, 12 Jun 2015 09:31:50 -0400 Richard Yao wrote: > On 06/12/2015 09:03 AM, Richard Yao wrote: > > On 06/11/2015 09:59 PM, Hans Petter Selasky wrote: > >> On 06/11/15 16:59, Richard Yao wrote: > >>> On 06/11/2015 10:52 AM, Ian Lepore wrote: > >>>> On Thu, 2015-06-11 at 10:49 -0400, Richard Yao wrote: > >>>>> On 06/06/2015 08:13 PM, Erich Dollansky wrote: > >>>> [...] > >>>>> > >>>>> The fastest portable way of calculating highest bit set is to > >>>>> use a debrujin sequence: > >>>>> > >>>>> https://graphics.stanford.edu/~seander/bithacks.html#IntegerLogDeBruijn > >>>>> > >>>>> The binary approach is inferior, especially on Pentium 4 > >>>>> processors. > >>>> > >>>> And of course it's crucial that we optimize for Pentium 4 > >>>> processors in 2015. > >>> > >>> The debrujin approach is fast regardless of the architecture. > >>> Anyway, this is a solved problem. There is no need to reinvent > >>> the wheel when the portable solutions are listed on that page at > >>> Stanford. > >>> > >> > >> Hi Richard, > >> > >> ffs() can be implemented like this simply: > >> > >> int ffs_A(uint32_t v) > >> { > >> static const int MultiplyDeBruijnBitPosition[32] = > >> { > >> 0, 9, 1, 10, 13, 21, 2, 29, 11, 14, 16, 18, 22, 25, 3, 30, > >> 8, 12, 20, 28, 15, 17, 24, 7, 19, 27, 23, 6, 26, 5, 4, 31 > >> }; > >> v = ~(v - 1) & v; > >> return (MultiplyDeBruijnBitPosition[(uint32_t)(v * 0x07C4ACDDU) >> > >> 27]); } > > > > There is a way to do that on the stanford page too: > > > > https://graphics.stanford.edu/~seander/bithacks.html#ZerosOnRightMultLookup > > My apologies. I inadvertently linked to the wrong variant of that in > my initial email. It has been a while since I visited that page and I > was juggling a few things when I wrote that email, so it was easy to > confuse the two. > > Anyway, it would be possible to do something like: > > #if defined(__GNUC__) || (defined(__clang__) && > __has_builtin(__builtin_ffs)) > # define ffs(n) __builtin_ffs(n) > #else > /* > * From Sean Eron Anderson's Bit Twiddling Hacks > * > https://graphics.stanford.edu/~seander/bithacks.html#ZerosOnRightMultLookup > */ > static inline int > ffs(uint32_t v) > { > static const int MultiplyDeBruijnBitPosition[32] = > { > 0, 9, 1, 10, 13, 21, 2, 29, 11, 14, 16, 18, 22, 25, 3, 30, > 8, 12, 20, 28, 15, 17, 24, 7, 19, 27, 23, 6, 26, 5, 4, 31 > }; > v = ~(v - 1) & v; > return (MultiplyDeBruijnBitPosition[(uint32_t)(v * 0x07C4ACDDU) >> > 27]); } > #endif > > If there were an autotools-like check for `__has_builtin()`, then an > explicit list of compilers known to support `__builtin_ffs()` would > not be necessary, although a list of compilers that lack support for > `__has_builtin()` (such as GCC) would still be necessary. Those > building with compilers that do not support `__builtin_ffs()` could > fallback to the DeBrujin approach. > From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 15 03:20:50 2015 Return-Path: Delivered-To: freebsd-hackers@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 02E3CC76 for ; Mon, 15 Jun 2015 03:20:50 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CD69EE78 for ; Mon, 15 Jun 2015 03:20:49 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from jre-mbp.elischer.org (ppp121-45-248-228.lns20.per4.internode.on.net [121.45.248.228]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t5F3Kb8o086950 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 14 Jun 2015 20:20:40 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <557E4480.6000603@freebsd.org> Date: Mon, 15 Jun 2015 11:20:32 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Don whY , FreeBSD-Hackers Mailing List Subject: Re: PXE boot an XIP image? References: <557C073E.1060702@gmx.com> <557C2BD7.1000104@freebsd.org> <557C844F.1010107@gmx.com> In-Reply-To: <557C844F.1010107@gmx.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2015 03:20:50 -0000 On 6/14/15 3:28 AM, Don whY wrote: > On 6/13/2015 6:10 AM, Julian Elischer wrote: >> On 6/13/15 6:34 PM, Don whY wrote: >> >>> I'd like to PXE boot a kernel then fetch (any choice of protocol) >>> a *single* image to load into RAM thereafter not requiring any >>> access to external media to operate. I.e., as if the image >>> had resided in the device all along. >> >> what do you mean by "single"? any PXE boot is by definition a >> number of >> transactions. > > Load kernel, load *an* executable, CUT NETWORK CORD. Thereafter, > behave > as if the device was operating from built-in FLASH. > >> The regular PXE boot code from FreeBSD is capable of loading a >> kernel and a >> matching ram filesystem, which when executed, will boot up as a >> running >> system and not touch any medium. I haven't done it for a while but at >> one stage there used to be a suitable memory filesystem on one fo >> the boot media. >> (that may no longer be true) > > A memory filesystem is not the same as XIP. You'd have *two* copies of > anything that is executing in RAM at any given time: the one stored > in the filesystem and the one that is executing in process memory. you didn't explain clearly you wanted "execute in place" (XIP) (or if you did you didn't explain what it means becasue I only figured it out from your other email). As far as I know there is no facility for that. It's an interesting concept.. You could probably start from tmpfs and add a 'preloaded image' feature and a vfs layer that uses a copy-on-write getpages entrypoint. But I think it's going to be you doing much of the work. You may need a special image activator to handle the loading. Others may chime in if there is work underway already but I don't recall hearing about such. From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 15 17:43:45 2015 Return-Path: Delivered-To: freebsd-hackers@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 326EF91B; Mon, 15 Jun 2015 17:43:45 +0000 (UTC) (envelope-from Don.whY@gmx.com) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C7A81B5; Mon, 15 Jun 2015 17:43:44 +0000 (UTC) (envelope-from Don.whY@gmx.com) Received: from [192.168.1.115] ([67.212.197.98]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LguAU-1ZP5LC482w-00oFj3; Mon, 15 Jun 2015 19:43:37 +0200 Message-ID: <557F0ED6.7010700@gmx.com> Date: Mon, 15 Jun 2015 10:43:50 -0700 From: Don whY User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Julian Elischer , FreeBSD-Hackers Mailing List Subject: Re: PXE boot an XIP image? References: <557C073E.1060702@gmx.com> <557C2BD7.1000104@freebsd.org> <557C844F.1010107@gmx.com> <557E4480.6000603@freebsd.org> In-Reply-To: <557E4480.6000603@freebsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:zM+8s73mRhHxQG7AcG5i4FU+Gm9d1I/n7hje90dAtx0W1whfG/x j8lOfG8XfYOpeEqyvVujKG7qDY6xAC7wBB2DBudv9RAYA+mGZozrajCv9xn8rlxdTxb5csA SWIjxuCIPtv72M4BqTVFsciATEHiKuHdx9qyTEelz67ACqWdPd0fFJ0ZQO76G9hBrRgRjbz zu7K1zKGicv5SoxjgVC4w== X-UI-Out-Filterresults: notjunk:1;V01:K0:ST7W5C+ecKo=:PEs81FJp+Tr6HTtaveScmp HQGthlwxqC382ob26t4SDKjr3CC+Txww3OrOVoiS3uZBlKVTjSIxkSJltzI2WozCDB59KoKbL weLObi+8ADT/smFyoyoEzJGuhopZoCxMtvM0/YqImMJcdt6cRu1VXnCaw+cZ9kyiVh3fg5Y35 UwwIMnvBfyKpMW6RecVpbz0F2fhVP/dpOPOdrkuRron7+eg/Bv4ZtQnrL3PJJcc24p7H5LvM1 sND/wpZl8KDmcdNxgH8/xLwHByf1MxNjUqFUqj4qDVgBZR9OQy4WtH7/Nby1zo90uw40YQD9p s9t5D4ZRhhYpUtodb+gKYeATtQb0t3D18d3hf7acC6ln7RwP1ABdeV6VsBHfRDdPjLIVd/LhE y0Psa7PkxvNlNZnHrfnFmIm4AqDfyDQCQtztFYYvMYkWqGkMf8N3G5soYl6wpV3GbedwgnFmH l2ygkRpYwd8nflJ2g+AUAbWPSOkUbozMB0uyu2vPBg3ajhEnZZlkmlHbw2g9nodCoi8K/2n2I 09/ViPbdxWRnz+Tm1n1kGdeN5OximV92PHTyGGhOkIDv43r5mpsdT9CttAYUCEixoVRtd7hyn bxLEndKeEHOM3+r9t2/XV8LOr7CPSzldOWaVyLh0v4FsDm2xyOWLqcGJSMZ68sSe24PB1vgg+ 6bYWWGl0bRF8JVehapsGSuVmCESToPR3fwZ8dF/phMai07AHw7w9h961JzRlguks7k2g= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2015 17:43:45 -0000 On 6/14/2015 8:20 PM, Julian Elischer wrote: > On 6/14/15 3:28 AM, Don whY wrote: >> On 6/13/2015 6:10 AM, Julian Elischer wrote: >>> On 6/13/15 6:34 PM, Don whY wrote: >>> >>>> I'd like to PXE boot a kernel then fetch (any choice of protocol) >>>> a *single* image to load into RAM thereafter not requiring any >>>> access to external media to operate. I.e., as if the image >>>> had resided in the device all along. >>> >>> what do you mean by "single"? any PXE boot is by definition a number of >>> transactions. >> >> Load kernel, load *an* executable, CUT NETWORK CORD. Thereafter, behave >> as if the device was operating from built-in FLASH. >> >>> The regular PXE boot code from FreeBSD is capable of loading a kernel and a >>> matching ram filesystem, which when executed, will boot up as a running >>> system and not touch any medium. I haven't done it for a while but at >>> one stage there used to be a suitable memory filesystem on one fo the boot >>> media. >>> (that may no longer be true) >> >> A memory filesystem is not the same as XIP. You'd have *two* copies of >> anything that is executing in RAM at any given time: the one stored >> in the filesystem and the one that is executing in process memory. > you didn't explain clearly you wanted "execute in place" (XIP) (or if you did you > didn't explain what it means becasue I only figured it out from your other > email). Sorry, "PXE boot an XIP image" was the best way I could describe my intent. :< Note that loading the kernel is exactly what I'm trying to do -- but with a good chunk of userland, too! (i.e., the kernel is loaded at boot into *memory*, not into a "filesystem" and begins executing -- AS IF it was operating out of FLASH) > As far as I know there is no facility for that. It's an interesting concept.. > You could probably start from tmpfs and add a 'preloaded image' feature and > a vfs layer that uses a copy-on-write getpages entrypoint. But I think it's > going to be > you doing much of the work. You may need a special image activator to handle > the loading. I was looking for more of a "hack" to exploit existing characteristics in a novel way -- in much the same way that crunchgen can be considered a "hack". > Others may chime in if there is work underway already but I don't recall > hearing about such. I don't think it is easily accomplished. The way I see it, you need a hack to allow you to transfer all of the appropriate binaries into RAM *as* process images (or something similar). Then, you need a way of invoking each, as needed (i.e., some *portion* of that RAM-based image). Finally, you need a way to ensure that you don't start duplicating TEXT in the process (else you've defeated your purpose). E.g., if you fork the single, combined (crunchgen'd) image each time you want to start a new process (run a new command embedded within that image), you can share the TEXT -- but, you now end up duplicating *all* of the DATA segment (including requirements for "other" commands folded into that image). You'd have to almost be converting each individual executable into its own little .so (and the modules that it requires into still other .so's) just so you could get that finer-grained "load/execute" capability of individual "programs" without the excess DATA segment costs. [And, at the same time, you'd have to arrange to fault all of these .so's into memory at IPL so they were present when/if needed] I just can't see a trick to work-around this basic "load/execute" assumption inherent in UN*X and other "desktop" OS's. From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 15 17:48:34 2015 Return-Path: Delivered-To: freebsd-hackers@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 34252A51 for ; Mon, 15 Jun 2015 17:48:34 +0000 (UTC) (envelope-from csprajeeth@gmail.com) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E9EB9EA for ; Mon, 15 Jun 2015 17:48:33 +0000 (UTC) (envelope-from csprajeeth@gmail.com) Received: by ykar6 with SMTP id r6so36131171yka.2 for ; Mon, 15 Jun 2015 10:48:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=1Ks/f8YIVlPz24jo6ktS9jcCpoZlhV7wOgedEOY928g=; b=MS7ugmFSS1gKOivpnKkQm83D65pKdrJtYAQfChNSTY1I/t2xkzZsXig+Jqqa5gQqTl a4wQks5LFLeLx5VjcsRzNWZQtP/GYSkQ+UWfnxdz1rxHQ5evbZN1oMIdTlYr3B6jNwfk mD0LYER0+8JJi84Je5Ofng6whcXUWcgsT+vcPPsJa2ulo1vAnAA0Sm31wTZTu8VEaIib 6lU+S7UQNnjJK/6pzwPOpTOPvTnYcJ7Qm064j8rhNufAkLMsxh4tEndOFyBdb9gs+vN5 uYwrLpFX9zkjdUPYdRYgt4j5n3fwU6oPyvHEHKBb3+3MphfHGfHyvehICrL/jTYpqt1v ZLIg== MIME-Version: 1.0 X-Received: by 10.170.100.67 with SMTP id r64mr35954001yka.9.1434390513047; Mon, 15 Jun 2015 10:48:33 -0700 (PDT) Received: by 10.37.194.134 with HTTP; Mon, 15 Jun 2015 10:48:32 -0700 (PDT) Date: Mon, 15 Jun 2015 23:18:32 +0530 Message-ID: Subject: PMCSTAT Event for counting L1-DCache Hit / Misses From: Sai Prajeeth To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2015 17:48:34 -0000 Hi, I am not able to find the event that counts the L1 Data cache hits and misses in pmccontrol -L. Can anyone tell me what the events are so that i can get the counts using pmcstat ?\ Thanks! From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 16 03:02:40 2015 Return-Path: Delivered-To: freebsd-hackers@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CB7507E0 for ; Tue, 16 Jun 2015 03:02:40 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 88AA3D2B for ; Tue, 16 Jun 2015 03:02:39 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t5G32Y3D092049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 15 Jun 2015 20:02:37 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <557F91C4.8080602@freebsd.org> Date: Tue, 16 Jun 2015 11:02:28 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Don whY , FreeBSD-Hackers Mailing List Subject: Re: PXE boot an XIP image? References: <557C073E.1060702@gmx.com> <557C2BD7.1000104@freebsd.org> <557C844F.1010107@gmx.com> <557E4480.6000603@freebsd.org> <557F0ED6.7010700@gmx.com> In-Reply-To: <557F0ED6.7010700@gmx.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2015 03:02:40 -0000 On 6/16/15 1:43 AM, Don whY wrote: > > I was looking for more of a "hack" to exploit existing > characteristics in a > novel way -- in much the same way that crunchgen can be considered a > "hack". > >> Others may chime in if there is work underway already but I don't >> recall >> hearing about such. > > I don't think it is easily accomplished. > > The way I see it, you need a hack to allow you to transfer all of the > appropriate binaries into RAM *as* process images (or something > similar). > Then, you need a way of invoking each, as needed (i.e., some *portion* > of that RAM-based image). Finally, you need a way to ensure that you > don't start duplicating TEXT in the process (else you've defeated > your purpose). > > E.g., if you fork the single, combined (crunchgen'd) image each time > you > want to start a new process (run a new command embedded within that > image), you can share the TEXT -- but, you now end up duplicating *all* > of the DATA segment (including requirements for "other" commands folded > into that image). If you had an image activator that loaded the text pages from the filesystem using page sharing, (possibly a tmpfs variant) you'd achieve what you want in the text segment, but as you say you'd still need data copying. > > You'd have to almost be converting each individual executable into its > own little .so (and the modules that it requires into still other > .so's) > just so you could get that finer-grained "load/execute" capability of > individual "programs" without the excess DATA segment costs. > > [And, at the same time, you'd have to arrange to fault all of these > .so's into memory at IPL so they were present when/if needed] > > I just can't see a trick to work-around this basic "load/execute" > assumption > inherent in UN*X and other "desktop" OS's. I think the two parts of the equation are: and image activator that loads the text segment by sharing and a matching filesystem that has an interface by which pages of a file can be available on a refcounted basis to the VM. given those two things it maybe able to have only no shared data taking up extra space on execute. For me it wouldn't be worth the extra work, but I could imagine some very small machines where it may be an advantage. > > From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 16 04:02:15 2015 Return-Path: Delivered-To: freebsd-hackers@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BA108D46; Tue, 16 Jun 2015 04:02:15 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5ADE7CAD; Tue, 16 Jun 2015 04:02:15 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t5G429LU015201 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 16 Jun 2015 07:02:09 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t5G429LU015201 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t5G4288H015200; Tue, 16 Jun 2015 07:02:08 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 16 Jun 2015 07:02:08 +0300 From: Konstantin Belousov To: Julian Elischer Cc: Don whY , FreeBSD-Hackers Mailing List Subject: Re: PXE boot an XIP image? Message-ID: <20150616040208.GG2080@kib.kiev.ua> References: <557C073E.1060702@gmx.com> <557C2BD7.1000104@freebsd.org> <557C844F.1010107@gmx.com> <557E4480.6000603@freebsd.org> <557F0ED6.7010700@gmx.com> <557F91C4.8080602@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <557F91C4.8080602@freebsd.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2015 04:02:15 -0000 On Tue, Jun 16, 2015 at 11:02:28AM +0800, Julian Elischer wrote: > On 6/16/15 1:43 AM, Don whY wrote: > > > > I was looking for more of a "hack" to exploit existing > > characteristics in a > > novel way -- in much the same way that crunchgen can be considered a > > "hack". > > > >> Others may chime in if there is work underway already but I don't > >> recall > >> hearing about such. > > > > I don't think it is easily accomplished. > > > > The way I see it, you need a hack to allow you to transfer all of the > > appropriate binaries into RAM *as* process images (or something > > similar). > > Then, you need a way of invoking each, as needed (i.e., some *portion* > > of that RAM-based image). Finally, you need a way to ensure that you > > don't start duplicating TEXT in the process (else you've defeated > > your purpose). > > > > > > E.g., if you fork the single, combined (crunchgen'd) image each time > > you > > want to start a new process (run a new command embedded within that > > image), you can share the TEXT -- but, you now end up duplicating *all* > > of the DATA segment (including requirements for "other" commands folded > > into that image). > If you had an image activator that loaded the text pages from the > filesystem > using page sharing, (possibly a tmpfs variant) you'd achieve what you > want in > the text segment, but as you say you'd still need data copying. > > > > You'd have to almost be converting each individual executable into its > > own little .so (and the modules that it requires into still other > > .so's) > > just so you could get that finer-grained "load/execute" capability of > > individual "programs" without the excess DATA segment costs. > > > > [And, at the same time, you'd have to arrange to fault all of these > > .so's into memory at IPL so they were present when/if needed] > > > > I just can't see a trick to work-around this basic "load/execute" > > assumption > > inherent in UN*X and other "desktop" OS's. > > I think the two parts of the equation are: > and image activator that loads the text segment by sharing > and a matching filesystem that has an interface by which pages of a file > can be available on a refcounted basis to the VM. > given those two things it maybe able to have only no shared data > taking up extra space on execute. > > For me it wouldn't be worth the extra work, but I could imagine some > very small machines where it may be an advantage. > Our tmpfs(5) provides the in-place execution capability, assuming the image has correctly aligned segments. From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 16 04:38:39 2015 Return-Path: Delivered-To: freebsd-hackers@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F41C944E for ; Tue, 16 Jun 2015 04:38:38 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C04D2654 for ; Tue, 16 Jun 2015 04:38:38 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t5G4cVGS092449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 15 Jun 2015 21:38:35 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <557FA842.7060803@freebsd.org> Date: Tue, 16 Jun 2015 12:38:26 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Konstantin Belousov CC: Don whY , FreeBSD-Hackers Mailing List Subject: Re: PXE boot an XIP image? References: <557C073E.1060702@gmx.com> <557C2BD7.1000104@freebsd.org> <557C844F.1010107@gmx.com> <557E4480.6000603@freebsd.org> <557F0ED6.7010700@gmx.com> <557F91C4.8080602@freebsd.org> <20150616040208.GG2080@kib.kiev.ua> In-Reply-To: <20150616040208.GG2080@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2015 04:38:39 -0000 On 6/16/15 12:02 PM, Konstantin Belousov wrote: > On Tue, Jun 16, 2015 at 11:02:28AM +0800, Julian Elischer wrote: >> On 6/16/15 1:43 AM, Don whY wrote: >>> I was looking for more of a "hack" to exploit existing >>> characteristics in a >>> novel way -- in much the same way that crunchgen can be considered a >>> "hack". >>> >>>> Others may chime in if there is work underway already but I don't >>>> recall >>>> hearing about such. >>> I don't think it is easily accomplished. >>> >>> The way I see it, you need a hack to allow you to transfer all of the >>> appropriate binaries into RAM *as* process images (or something >>> similar). >>> Then, you need a way of invoking each, as needed (i.e., some *portion* >>> of that RAM-based image). Finally, you need a way to ensure that you >>> don't start duplicating TEXT in the process (else you've defeated >>> your purpose). >>> >> >>> E.g., if you fork the single, combined (crunchgen'd) image each time >>> you >>> want to start a new process (run a new command embedded within that >>> image), you can share the TEXT -- but, you now end up duplicating *all* >>> of the DATA segment (including requirements for "other" commands folded >>> into that image). >> If you had an image activator that loaded the text pages from the >> filesystem >> using page sharing, (possibly a tmpfs variant) you'd achieve what you >> want in >> the text segment, but as you say you'd still need data copying. >>> You'd have to almost be converting each individual executable into its >>> own little .so (and the modules that it requires into still other >>> .so's) >>> just so you could get that finer-grained "load/execute" capability of >>> individual "programs" without the excess DATA segment costs. >>> >>> [And, at the same time, you'd have to arrange to fault all of these >>> .so's into memory at IPL so they were present when/if needed] >>> >>> I just can't see a trick to work-around this basic "load/execute" >>> assumption >>> inherent in UN*X and other "desktop" OS's. >> I think the two parts of the equation are: >> and image activator that loads the text segment by sharing >> and a matching filesystem that has an interface by which pages of a file >> can be available on a refcounted basis to the VM. >> given those two things it maybe able to have only no shared data >> taking up extra space on execute. >> >> For me it wouldn't be worth the extra work, but I could imagine some >> very small machines where it may be an advantage. >> > Our tmpfs(5) provides the in-place execution capability, assuming the image > has correctly aligned segments. cool.. but I guess you'd have to load it up from the net before you could use it. Is this documented anywhere? From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 16 05:04:44 2015 Return-Path: Delivered-To: freebsd-hackers@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 661A4B1C; Tue, 16 Jun 2015 05:04:44 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E5FA6D39; Tue, 16 Jun 2015 05:04:43 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t5G54c3W029231 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 16 Jun 2015 08:04:38 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t5G54c3W029231 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t5G54cWc029230; Tue, 16 Jun 2015 08:04:38 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 16 Jun 2015 08:04:38 +0300 From: Konstantin Belousov To: Julian Elischer Cc: Don whY , FreeBSD-Hackers Mailing List Subject: Re: PXE boot an XIP image? Message-ID: <20150616050438.GI2080@kib.kiev.ua> References: <557C073E.1060702@gmx.com> <557C2BD7.1000104@freebsd.org> <557C844F.1010107@gmx.com> <557E4480.6000603@freebsd.org> <557F0ED6.7010700@gmx.com> <557F91C4.8080602@freebsd.org> <20150616040208.GG2080@kib.kiev.ua> <557FA842.7060803@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <557FA842.7060803@freebsd.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2015 05:04:44 -0000 On Tue, Jun 16, 2015 at 12:38:26PM +0800, Julian Elischer wrote: > On 6/16/15 12:02 PM, Konstantin Belousov wrote: > > Our tmpfs(5) provides the in-place execution capability, assuming the image > > has correctly aligned segments. > cool.. but I guess you'd have to load it up from the net before you > could use it. > Is this documented anywhere? > Documented what ? A way to populate tmpfs mount with some data ? I think tar xf might be enough. From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 16 05:18:12 2015 Return-Path: Delivered-To: freebsd-hackers@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C7E6AE84 for ; Tue, 16 Jun 2015 05:18:12 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 861CDF78 for ; Tue, 16 Jun 2015 05:18:12 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by qcsf5 with SMTP id f5so1522664qcs.2 for ; Mon, 15 Jun 2015 22:18:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=skuwigmyyVlygFgOpJVA0+iaUR7/oHsrICR6rINQLBM=; b=avXzaGHkAt7299uDt8wil6J9ZWCujZd8dL26yzpCu37Ws7I4hfQrh41TpEgm3TAf2J Il9uLyU2JvK5P36M86uvwrprDqEriYNf3bnciSvzDf7s2xNtR05AldboAZgezNJdemM5 ZeM8EbIo42M2l5UW30Dv7eVoEAz/YG5YPadiNrDPTYj8JfZ3m7PxOKE+TTBnDtSdwqLw 2kVKQRQjYP/Z1UIa84NYPzSm2RM6y06eA0IQfNSwKgKiv189AA8e8FVtO98OW3SckKHq JqKALSf1XM2UNwQOdfUVx4QAe0oeoMOQeq8Og1gpcJgxpEIsdInAj7YDrbXn+bDf03t1 wtng== MIME-Version: 1.0 X-Received: by 10.55.52.12 with SMTP id b12mr65757814qka.22.1434431891606; Mon, 15 Jun 2015 22:18:11 -0700 (PDT) Received: by 10.140.98.73 with HTTP; Mon, 15 Jun 2015 22:18:11 -0700 (PDT) In-Reply-To: <557C073E.1060702@gmx.com> References: <557C073E.1060702@gmx.com> Date: Mon, 15 Jun 2015 22:18:11 -0700 Message-ID: Subject: Re: PXE boot an XIP image? From: NGie Cooper To: Don whY Cc: FreeBSD-Hackers Mailing List Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2015 05:18:12 -0000 On Sat, Jun 13, 2015 at 3:34 AM, Don whY wrote: > Hi, > > Apologies as to whether this belongs here... or on -embedded. :< > > I'd like to PXE boot a kernel then fetch (any choice of protocol) > a *single* image to load into RAM thereafter not requiring any > access to external media to operate. I.e., as if the image > had resided in the device all along. > > A crude approach *might* be something like crunchgen'ing init > with all of the (static linked) binaries that are required > and letting the loaded kernel NFS read (load) that init(1). > Obviously, I'd trim the kernel and other binaries down to the > bare essentials to minimize RAM requirements (as there would be no > swap, etc.) > > [I.e., creating a tiny filesystem that simply links every executable > back to this *one* image] > > In practice, this won't (?) really work as hoped. Any pointers on > a proven technique to achieve these results? > > Thanks! This may or may not be helpful: http://blog.hostileadmin.com/2012/05/04/pxe-booting-into-a-freebsd-installation/ (note: it's using grub). If you do are using loader(8) though, `load -t mfs_root /path/to/mfsroot.gz`, will load the mfsroot into RAM. You could employ tricks used by NanoBSD-based platforms, etc to say "boot diskless" as well (look for rc.initdiskless). You don't need to boot over NFS. That and you could use what kib described later on, but that requires additional scripting. There's mdconfig as well, but some folks I know didn't care for it because it "wasn't really well documented". Cheers! -NGie PS Thank you for the reminder about documenting -t mfs_root in loader(8). From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 16 06:43:23 2015 Return-Path: Delivered-To: freebsd-hackers@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 04FBD401; Tue, 16 Jun 2015 06:43:23 +0000 (UTC) (envelope-from Don.whY@gmx.com) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 84CBEAA6; Tue, 16 Jun 2015 06:43:22 +0000 (UTC) (envelope-from Don.whY@gmx.com) Received: from [192.168.1.115] ([67.212.197.98]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MRocn-1Ybqog399l-00Sz0t; Tue, 16 Jun 2015 08:43:20 +0200 Message-ID: <557FC599.1040807@gmx.com> Date: Mon, 15 Jun 2015 23:43:37 -0700 From: Don whY User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Julian Elischer , FreeBSD-Hackers Mailing List Subject: Re: PXE boot an XIP image? References: <557C073E.1060702@gmx.com> <557C2BD7.1000104@freebsd.org> <557C844F.1010107@gmx.com> <557E4480.6000603@freebsd.org> <557F0ED6.7010700@gmx.com> <557F91C4.8080602@freebsd.org> In-Reply-To: <557F91C4.8080602@freebsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:hH/tMylvFiq68SJ2atdRdnL8km5iyyamgthNNAxp2BPMkbQ4XRh MLAdggTg8fj0bHZ2fIUYH0A09cv1qcQDVc43S4o1NmudM5VuGZr1jxOKSKpXZ4rRttKlevx 0kNLQNGx8LzRMi89z+I6AWaK4T8mfHb4xA6mNvRZkDCKSXv3PXorqZ/H+PoAAM4Li3cuupj xEblqQUGYoN2QVKO/YH1Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:ZsFFHylIYcU=:eel2y7S9FGhEMdw/6fzs5r a7lk1RSRJYx5plXr2S49PMA1enxeNarWnkBaDBHTvmLjrz9DsrgV/dS0EL/5edOVJgYagCYzc MVWX6Zk+9UR2Q1iMtooM4TMolYwZudKN+2MKoneNNP0BfGJ6XdTKaHbO28oOwvm9DpDQIAgbY XwrvNEJAS3d4VoDUk3HrNBbf4e6Olx1yHdvnh8UnnoQmac/gNvXQwW8PA/9vH03FCd1WFSe1i KeVmCRIwE0vi6Xt3d1ypaLMb1UA0LBELzwNLHUTPr9WyYKzCvkeRFPmmY6q4ttI//d1QaO4gE oTgvhnmX+OTQVUJa/edVuXSR2Uxa8vnTUMgeJd8Hfmn75DyxM3aXBkvNk+4tc+ZKZtiMs6SAq ExCF+x8Tr6RnU0GPNovc5TazyyafOjZzUSwDXjvRVbi5Rvdn1FU84ZgoFMa2kxwx86qt1s4Mf HDfOiWJTWlsTSq4ro8nvQnfS9H8l0uyRzVufgX724bCeT8l1hVf7vScOeRouvwLsDwndmk03W hmqNGWwRBfHzBQXQa0Esr+9Hx3eyxmv1iWvnpx4BjfW81QiEyvWOOe+O9NIpy3Ky42ddVBaxF kgmnDPEKeN+Sq+NKjRvZdESqFxZAUJU/RVc7UUsHgEA75MLyjmhEbRev5nPhBc2QxNgh90UOC YAMUHyosBJPFn3tWlc0uSkKsLYuXq9S+n+cMITbdRjbhwfDve1EqHrcIo96qZI/KZ6LQ= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2015 06:43:23 -0000 On 6/15/2015 8:02 PM, Julian Elischer wrote: > On 6/16/15 1:43 AM, Don whY wrote: >> >> I was looking for more of a "hack" to exploit existing characteristics in a >> novel way -- in much the same way that crunchgen can be considered a "hack". >> I just can't see a trick to work-around this basic "load/execute" assumption >> inherent in UN*X and other "desktop" OS's. > > I think the two parts of the equation are: > and image activator that loads the text segment by sharing > and a matching filesystem that has an interface by which pages of a file > can be available on a refcounted basis to the VM. > given those two things it maybe able to have only no shared data taking up > extra space on execute. > > For me it wouldn't be worth the extra work, but I could imagine some very small > machines where it may be an advantage. I'm *sure* it has little-to-no value in a "resource-rich" environment (e.g., most places where UN*X variants are deployed). OTOH, SoC-based systems (typically resource-starved) win each time you can save a byte! I was hoping I could build on a FOSS platform and leave much of the products' support/evolution to "others". Building on a proprietary RTOS makes that impractical. :-/ From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 16 09:11:02 2015 Return-Path: Delivered-To: freebsd-hackers@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8B60CE45 for ; Tue, 16 Jun 2015 09:11:02 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6064D175 for ; Tue, 16 Jun 2015 09:11:02 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t5G9AtNC093400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 16 Jun 2015 02:10:59 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <557FE81A.3090607@freebsd.org> Date: Tue, 16 Jun 2015 17:10:50 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Konstantin Belousov CC: Don whY , FreeBSD-Hackers Mailing List Subject: Re: PXE boot an XIP image? References: <557C073E.1060702@gmx.com> <557C2BD7.1000104@freebsd.org> <557C844F.1010107@gmx.com> <557E4480.6000603@freebsd.org> <557F0ED6.7010700@gmx.com> <557F91C4.8080602@freebsd.org> <20150616040208.GG2080@kib.kiev.ua> <557FA842.7060803@freebsd.org> <20150616050438.GI2080@kib.kiev.ua> In-Reply-To: <20150616050438.GI2080@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2015 09:11:02 -0000 On 6/16/15 1:04 PM, Konstantin Belousov wrote: > On Tue, Jun 16, 2015 at 12:38:26PM +0800, Julian Elischer wrote: >> On 6/16/15 12:02 PM, Konstantin Belousov wrote: >>> Our tmpfs(5) provides the in-place execution capability, assuming the image >>> has correctly aligned segments. >> cool.. but I guess you'd have to load it up from the net before you >> could use it. >> Is this documented anywhere? >> > Documented what ? A way to populate tmpfs mount with some data ? > I think tar xf might be enough. No silly, the fact that it allows in-place execution where the text pages of the binary are mapped directly to the text pages of the running process image. > > From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 16 12:19:08 2015 Return-Path: Delivered-To: freebsd-hackers@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BFDFFBB1 for ; Tue, 16 Jun 2015 12:19:08 +0000 (UTC) (envelope-from steven@pyro.eu.org) Received: from manchester-1.man.uk.cluster.ok24.net (unknown [IPv6:2001:41c8:51:40::1]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 59C05605 for ; Tue, 16 Jun 2015 12:19:07 +0000 (UTC) (envelope-from steven@pyro.eu.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=simple/simple; d=pyro.eu.org; s=06.2015; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=WzAx3wUimQjr/OplAmRN121PECA9qhW8rGbolJNjtII=; b=Cj4MW9saDyaCijIfoSAwMLVgVjhCIv2qOJQg+HbZWkyBLvmyMJJ1ZLF5xBUh1O0iVLLMoD+4vLQsen8ncv61tUJWyySZcAOO7rZCzEE5hee/smAlkk467LeXzX0DNYhMDW6uTpuPchavy8V74oUd0oyaDFOwQSDyMVW7lJFJR/0=; X-Spam-Status: No, score=-1.1 required=2.0 tests=ALL_TRUSTED, BAYES_00, DKIM_ADSP_DISCARD Received: from guisborough-1.rcc.uk.cluster.ok24.net ([217.155.40.118] helo=smtp.ok24.net) by manchester-1.man.uk.cluster.ok24.net with esmtp (Exim 4.80) (envelope-from ) id 1Z4ppS-0003cR-9m; Tue, 16 Jun 2015 13:19:04 +0100 Received: from kfreebsd-amd64.pyro.eu.org (smtp.ok24.net [10.1.1.1]) by smtp.ok24.net (Postfix) with ESMTPS id 257E211939A; Tue, 16 Jun 2015 13:18:58 +0100 (BST) Received: by kfreebsd-amd64.pyro.eu.org (Postfix, from userid 1000) id 1E65644CE; Tue, 16 Jun 2015 13:18:58 +0100 (BST) Date: Tue, 16 Jun 2015 13:18:58 +0100 From: Steven Chamberlain To: Holger Levsen Cc: "freebsd-hackers@freebsd.org" , "debian-bsd@lists.debian.org" Subject: Re: reproducible builds of FreeBSD in a chroot on Linux Message-ID: <20150616121857.GC14653@pyro.eu.org> References: <20150511183740.GA20721@pyro.eu.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="x+6KMIRAuhnl3hBn" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2015 12:19:08 -0000 --x+6KMIRAuhnl3hBn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Holger! On 5/7/15 5:22 PM, Holger Levsen wrote: > Here's the catch: I have basically no clue about freebsd - and I want to > build on Debian linux (on amd64) in a chroot. As Ed Maste points out, building it on a Linux chroot might not be representative of whether FreeBSD's own build system makes reproducible binaries or not. Ed Maste wrote: > If it's to help FreeBSD overall with reproducible > builds, then using the FreeBSD build infrastructure on a FreeBSD > kernel ... is an important part of the story. I can think of two other options: * ssh to a real FreeBSD build system, trigger builds there and take copies of the output files for analysis; * build in a FreeBSD chroot/jail on Debian GNU/kFreeBSD; so that you have the familiar Debian tools and could run as a Jenkins slave (which I'd particularly like, because it should be useful for other QA jobs too). On a kfreebsd-amd64 host I was able to complete a `make universe` - a build of all FreeBSD (10.1) for all architectures - using a bare FreeBSD jail. Then I can look at the build tree and object files, from the Debian host system, and compare those with a subsequent, clean build. For now I only did a simple diff. The differences are quite typical of what has been seen from Debian's reproducibility work - timestamps added by the build system: diff -Nr -U0 obj1/arm.arm/usr/home/build/src/include/vers.c obj2/arm.arm/us= r/home/build/src/include/vers.c --- obj1/arm.arm/usr/home/build/src/include/vers.c 2015-05-31 22:51:27= =2E000000000 +0000 +++ obj2/arm.arm/usr/home/build/src/include/vers.c 2015-06-03 00:12:51= =2E000000000 +0000 @@ -28,2 +28,2 @@ -#define SCCSSTR "@(#)FreeBSD 10.1-RELEASE-p10 #0 r283831: Sun May 31 22:51= :24 UTC 2015" -#define VERSTR "FreeBSD 10.1-RELEASE-p10 #0 r283831: Sun May 31 22:51:24 U= TC 2015\n build@freebsd:/home/build/obj/arm.arm/usr/home/build/src/inclu= de\n" +#define SCCSSTR "@(#)FreeBSD 10.1-RELEASE-p10 #0 r283831: Wed Jun 3 00:12= :48 UTC 2015" +#define VERSTR "FreeBSD 10.1-RELEASE-p10 #0 r283831: Wed Jun 3 00:12:48 U= TC 2015\n build@freebsd:/home/build/obj/arm.arm/usr/home/build/src/inclu= de\n" --- obj1/arm.arm/usr/home/build/src/sys/boot/arm/uboot/vers.c 2015-05-31 = 23:18:17.000000000 +0000 +++ obj2/arm.arm/usr/home/build/src/sys/boot/arm/uboot/vers.c 2015-06-03 = 00:40:02.000000000 +0000 @@ -3 +3 @@ -char bootprog_date[] =3D "Sun May 31 23:18:17 UTC 2015"; +char bootprog_date[] =3D "Wed Jun 3 00:40:02 UTC 2015"; And then obviously, vers.o differs, and so do the kernel images. For this particular kernel (CNS11XXNAS arm), it was actually the only difference: --- kernel-hexdump1.txt 2015-06-16 13:12:27.000000000 +0100 +++ kernel-hexdump2.txt 2015-06-16 13:12:33.000000000 +0100 @@ -242194,2 +242194,2 @@ -003b5ff0 72 32 38 33 38 33 31 3a 20 4d 6f 6e 20 4a 75 6e |r283831: Mon = Jun| -003b6000 20 20 31 20 30 31 3a 30 39 3a 32 31 20 55 54 43 | 1 01:09:21 = UTC| +003b5ff0 72 32 38 33 38 33 31 3a 20 57 65 64 20 4a 75 6e |r283831: Wed = Jun| +003b6000 20 20 33 20 30 32 3a 32 37 3a 33 39 20 55 54 43 | 3 02:27:39 = UTC| @@ -242201,2 +242201,2 @@ -003b6070 38 33 31 3a 20 4d 6f 6e 20 4a 75 6e 20 20 31 20 |831: Mon Jun = 1 | -003b6080 30 31 3a 30 39 3a 32 31 20 55 54 43 20 32 30 31 |01:09:21 UTC = 201| +003b6070 38 33 31 3a 20 57 65 64 20 4a 75 6e 20 20 33 20 |831: Wed Jun = 3 | +003b6080 30 32 3a 32 37 3a 33 39 20 55 54 43 20 32 30 31 |02:27:39 UTC = 201| Regards, --=20 Steven Chamberlain steven@pyro.eu.org --x+6KMIRAuhnl3hBn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/kFreeBSD) iQEcBAEBCAAGBQJVgBQwAAoJELrpzbaMAu5TLlkH/AnY402Xexjy22vZd5plgeQI x+D1C7jNcVK54BspxMRSk22R6G8laA4jmlan/DkqHDmFMIVU4jP5i/8qne1fi+S7 n6kqvt3FMwbmhu2dLbMrAzUyaUZ0JodxbudRPhr82/iDejMyugqeVsq1aEoJN4E3 NJzzWyso9gMhaoYRyOnNzGlHjtP9KIwEwnT3h6eUHEVozQJY0xgXg9EMnicSo9br tCwyOfZHuywf5kc8LtoWy1w/7PzN6QMrjmRZEJ9/krYVDZniEgUWstrb6FXkLhzX HPLjRquf/4MQbDHiauv9q6ltmW5Oplo747I+LrwJesLJXcFhrYd1qJg0rxrDv1M= =Jf+b -----END PGP SIGNATURE----- --x+6KMIRAuhnl3hBn-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 16 21:57:51 2015 Return-Path: Delivered-To: freebsd-hackers@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 999574A7 for ; Tue, 16 Jun 2015 21:57:51 +0000 (UTC) (envelope-from holger@layer-acht.org) Received: from alpha.holgerlevsen.de (mail.holgerlevsen.de [62.201.164.66]) by mx1.freebsd.org (Postfix) with ESMTP id 233D47A2 for ; Tue, 16 Jun 2015 21:57:50 +0000 (UTC) (envelope-from holger@layer-acht.org) Received: from localhost (alpha.holgerlevsen.de [62.201.164.66]) by alpha.holgerlevsen.de (Postfix) with ESMTP id F0101CAD63C; Tue, 16 Jun 2015 23:50:49 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alpha.holgerlevsen.de Received: from alpha.holgerlevsen.de ([62.201.164.66]) by localhost (mail.holgerlevsen.de [62.201.164.66]) (amavisd-new, port 10024) with ESMTP id W6WcHP21dyWn; Tue, 16 Jun 2015 23:50:48 +0200 (CEST) Received: from matrix.localnet (epsilon.holgerlevsen.de [62.201.164.82]) by alpha.holgerlevsen.de (Postfix) with ESMTP id CFA9ECAD089; Tue, 16 Jun 2015 23:50:48 +0200 (CEST) From: Holger Levsen To: freebsd-hackers@freebsd.org Subject: Re: reproducible builds of FreeBSD in a chroot on Linux Date: Tue, 16 Jun 2015 23:50:09 +0200 User-Agent: KMail/1.13.7 (Linux/3.16.0-0.bpo.4-amd64; KDE/4.8.4; x86_64; ; ) Cc: reproducible-builds@lists.alioth.debian.org References: <201505071122.36037.holger@layer-acht.org> <554B509B.8020608@fuckner.net> In-Reply-To: <554B509B.8020608@fuckner.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3591167.s3AzNQLD7r"; protocol="application/pgp-signature"; micalg=pgp-sha512 Content-Transfer-Encoding: 7bit Message-Id: <201506162350.11646.holger@layer-acht.org> X-Mailman-Approved-At: Tue, 16 Jun 2015 23:25:02 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2015 21:57:51 -0000 --nextPart3591167.s3AzNQLD7r Content-Type: Text/Plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Hi, sorry for replying so late... on the plus side, I've got a much clearer=20 picture now and I've implemented something similar, eg see https://reproducible.debian.net/openwrt/ and/or https://reproducible.debian.net/coreboot/ On the original subject of my mail: I have given up on this and will build= =20 =46reeBSD on a FreeBSD system, not in a chroot on Linux. I expected this wo= uld=20 work, learned that it doesn't and on the way also learned that one can buil= d=20 NetBSD on Linux or probably anything ;-) So in a while, I expect to have set up=20 https://reproducible.debian.net/freebsd/ as well as=20 https://reproducible.debian.net/netbsd/ - but no promises (yet), but these = are=20 my plans ;-) And to reply to some of you... On Donnerstag, 7. Mai 2015, Michael Fuckner wrote: > > I'm one of the people involved in > > https://wiki.debian.org/ReproducibleBuilds and have set up > > https://reproducible.debian.net which continously tests all packages in > > the Debian archive for build reproducibility (so far on amd64 only). > what is this good for? Testing the Compiler, track changes or check > hardware (errors on memory or disk) "Reproducible builds enable anyone to reproduce bit by bit identical binary= =20 packages from a given source, so that anyone can verify that a given binary= =20 derived from the source it was said to be derived. " - right now you have t= o=20 *believe* someone that the binary really comes from said source. And you ne= ed=20 to *believe* the system building it wasn't compromised... This is explained in more detail in our wiki or in the talks given, which a= re=20 linked in the wiki as well. On Freitag, 8. Mai 2015, Julian Elischer wrote: > also: By "FreeBSD" do you mean the kernel? or the whole system? > Unlike Linux, FreeBSD includes most of what the Linux world would > consider to be the domain of the base distro.. e.g. cat, ls, cc, etc. I mean the whole system (what you get when you run "make world") as well as= =20 the ports. https://wiki.freebsd.org/ReproducibleBuilds claims there are 3 known issues= =20 (for "make world" AIUI) for HEAD, I would like to build twice and verify=20 myself. https://wiki.freebsd.org/PortsReproducibleBuilds says "Of the 23599 package= s=20 which were built in both runs, 15164 have the same checksum when using the= =20 previously mentioned patch, giving 64.25% reproducible packages." - I'm als= o=20 curious to re-confirm this - and set up a test bed, which can be triggered= =20 regularily and easily. Our jenkins set up allows this and I'm interested to= do=20 this. (And I wouldn't be surprised nor disappointed if it took me til August or=20 September until I actually get around to tests the ports. The base system I= =20 definitly want to have results on in July.) =20 > There may also be a better mailing list for this... which? On Montag, 11. Mai 2015, Ed Maste wrote: > A lot of this depends on the motivation for pursuing reproducible > FreeBSD builds. If it's to help FreeBSD overall with reproducible > builds, then using the FreeBSD build infrastructure on a FreeBSD > kernel (e.g., a FreeBSD jail on Debian kFreeBSD) is an important part > of the story. If it's specifically for reproducible kernel builds for > kFreeBSD then the FreeBSD build infrastructure isn't relevant. My interest is to help FreeBSD with reproducible builds as I want to see=20 reproducible builds become the norm in the free software world and as I=20 believe FreeBSD is an important part of this world. And also because I'm=20 curious. :) As such, I'll set up a FreeBSD host "on" jenkins.debian.net (in that virtua= l=20 datacenter providing that host), running FreeBSD kernel and userland - to t= est=20 =46reeBSD on Debian ressources :-) Because we care and we can. Debian's kfreebsd-amd64 to me here is "just" another Debian architecture=20 (sorry Steven!), which will (hopefully) benefit from the Debian reproducibl= e=20 builds like all the other Debian architectures.=20 (And I wrote "hopefully" because kfreebsd-amd64 was a bit special for jessi= e=20 and hopefully will be a proper architecture for stretch, the release coming= in=20 two years.) I'll come back once these FreeBSD tests are set up. cheers, Holger --nextPart3591167.s3AzNQLD7r Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIVAwUAVYCaEwkauFYGmqocAQrJtw//TVsRIghgP3DJPifNyKcKP9SLJz3rqEyF edR2GPr0bt542cRiRENHR8xiZCr1HV2892zwv9quYwZ/4yecGSspYECN2Cl9MFuC +JR3SxCao855h1N3gLsj7dAHEefQHGrrOuaN4VNXt2DYjxqZYGtPj6hHU+w5qvdW KDTsJuF813RZ69Ij0Gd9/KfGa90WN13xPpRxU+1gJD68jDcJcSqXQ3VIyDXww17r jg1qynTxOJtM3ipYqKIRPccl7bNWXWui7wIKvJD8Ea/eMttVimG/aEs1dmLAqkNj ZWoplLEj/YnC/dmSsHW+FVbWTSTcga/Wp4hXj7KNYc3I1uWZd5J7//cNw4qlDdLq XtRjIYl7vME7tnDfY+4duEgZ0IEYgVKqS8gJBhyvD9NHe3f6LQaM2C5NuiW7OK+U oysgaAZb6oiwx2dDRilrasZt09CLkYLBu8qR4K6r2vluawW3V2PWN+kRBXjfqEQY KeRdWwToKV0RH6J53CfyPPSdf8mdFd/CT/mg1IsXJkFqlyPDwd9h4D3hfjdhH3uH m5EJGweWgMC/zsI1sNOCgXDwWvX1llsGLkcACHeSdCHjHmhGn4Lju+cPU0BL8D8Z LWTyy6WacYCd4JL/lWQaXqeLj11v0VWf46GJBlUNP4IG8puwIsDf9ZYDlaEueCFN +cj6hX11ZRo= =jYWP -----END PGP SIGNATURE----- --nextPart3591167.s3AzNQLD7r-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 17 12:36:08 2015 Return-Path: Delivered-To: freebsd-hackers@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6EB242416 for ; Wed, 17 Jun 2015 12:36:08 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2DE019BF for ; Wed, 17 Jun 2015 12:36:08 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from [78.35.158.162] (helo=fabiankeil.de) by smtprelay05.ispgateway.de with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.84) (envelope-from ) id 1Z58wT-0007Hx-5o; Wed, 17 Jun 2015 10:43:29 +0200 Date: Wed, 17 Jun 2015 10:43:32 +0200 From: Fabian Keil To: Holger Levsen Cc: freebsd-hackers@freebsd.org Subject: Re: reproducible builds of FreeBSD in a chroot on Linux Message-ID: <33a87f86.7b4c928e@fabiankeil.de> In-Reply-To: <201506162350.11646.holger@layer-acht.org> References: <201505071122.36037.holger@layer-acht.org> <554B509B.8020608@fuckner.net> <201506162350.11646.holger@layer-acht.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/ZpbHUX4VY=e01Z98FRkEWm3"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2015 12:36:08 -0000 --Sig_/ZpbHUX4VY=e01Z98FRkEWm3 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Holger Levsen wrote: > So in a while, I expect to have set up=20 > https://reproducible.debian.net/freebsd/ as well as=20 > https://reproducible.debian.net/netbsd/ - but no promises (yet), but > these are my plans ;-) Awesome. =20 > On Freitag, 8. Mai 2015, Julian Elischer wrote: > > also: By "FreeBSD" do you mean the kernel? or the whole system? > > Unlike Linux, FreeBSD includes most of what the Linux world would > > consider to be the domain of the base distro.. e.g. cat, ls, cc, etc. >=20 > I mean the whole system (what you get when you run "make world") as well > as the ports. >=20 > https://wiki.freebsd.org/ReproducibleBuilds claims there are 3 known > issues (for "make world" AIUI) for HEAD, I would like to build twice and > verify myself. The page is out of date, but luckily most of the issues are trivial to fix and there's work in progress to upstream the patches from ElectroBSD whose distfiles already built reproducible on amd64: https://www.fabiankeil.de/gehacktes/electrobsd/#reproducible-electrobsd The only non-trivial issue I run into was the efi boot stuff, but as I don't have the hardware for it anyway, I just detached it from the built for now and didn't spent a lot of time investigating. Obviously this "solution" is unlikely to fly for FreeBSD. Some of the other patches would require some polishing as well. Fabian --Sig_/ZpbHUX4VY=e01Z98FRkEWm3 Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlWBMzAACgkQBYqIVf93VJ3nyACeNexJpzVkolKwCSqI6YyyoEzK TSgAnAhIFHq4/Wn8bfV5IjMEq1z7t3qX =7Vvx -----END PGP SIGNATURE----- --Sig_/ZpbHUX4VY=e01Z98FRkEWm3-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 17 13:29:26 2015 Return-Path: Delivered-To: freebsd-hackers@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5AA844CA for ; Wed, 17 Jun 2015 13:29:26 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 9BAE1F1 for ; Wed, 17 Jun 2015 13:29:25 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA27594; Wed, 17 Jun 2015 16:29:23 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Z5DP9-000Bx6-Ay; Wed, 17 Jun 2015 16:29:23 +0300 Message-ID: <558175FA.4040106@FreeBSD.org> Date: Wed, 17 Jun 2015 16:28:26 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Konstantin Belousov , "freebsd-hackers@freebsd.org" Subject: Re: allow ffs & co. a binary search References: <20150607081315.7c0f09fb@B85M-HD3-0.alogt.com> <5573EA5E.40806@selasky.org> <20150607195245.62dc191f@B85M-HD3-0.alogt.com> <20150607135453.GH2499@kib.kiev.ua> In-Reply-To: <20150607135453.GH2499@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2015 13:29:26 -0000 On 07/06/2015 16:54, Konstantin Belousov wrote: > On Sun, Jun 07, 2015 at 07:52:45PM +0800, Erich Dollansky wrote: >> What I saw is that all CPUs except ARM uses the software version [of ffs]. > > Without quantifiers, this statement is not true. i386 libc function ffs(3) > uses bsfl instruction to do the job. Compilers know about ffs(3) and friends > as well, so e.g. gcc 5.1.0 generates the following code for the given > fragment: > return (ffs(x) + 1); > is translated to > 0: 0f bc c7 bsf %edi,%eax > 3: ba ff ff ff ff mov $0xffffffff,%edx > 8: 0f 44 c2 cmove %edx,%eax > b: 83 c0 02 add $0x2,%eax > (arg in %edi, result in %eax). > > I wrote a patch for amd64 libc long time ago to convert ffs/fls etc to use > of the bitstring instruction, but Bruce Evans argued that this would be > excessive. Your patch is excessive for the similar reasons. Out of curiosity, what are those (Bruce's) reasons? > My guess is that significantly clever compiler would recognize a pattern > used by native ffs implementation and automatically use bitstring > instructions. E.g., this already happens with popcnt and recent > gcc/clang, I am just lazy to verify ffs. It seems that both clang and gcc are smart enough to replace ffs*() with __builtin_ffs*() which expand to the corresponding instructions. On the other hand, neither clang nor gcc has __builtin_fls*() and as far as I can see neither does anything special for fls*() calls. Funny that __builtin_clz is complemented by __builtin_ctz, but there is no counterpart to __builtin_ffs. Lastly, I see no reason to have have different implementations of these functions for the kernel and userland. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 17 13:17:51 2015 Return-Path: Delivered-To: freebsd-hackers@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 18ABD69 for ; Wed, 17 Jun 2015 13:17:51 +0000 (UTC) (envelope-from holger@layer-acht.org) Received: from alpha.holgerlevsen.de (mail.holgerlevsen.de [62.201.164.66]) by mx1.freebsd.org (Postfix) with ESMTP id 975E7C9D for ; Wed, 17 Jun 2015 13:17:50 +0000 (UTC) (envelope-from holger@layer-acht.org) Received: from localhost (alpha.holgerlevsen.de [62.201.164.66]) by alpha.holgerlevsen.de (Postfix) with ESMTP id D29E6CAD1D1; Wed, 17 Jun 2015 11:39:19 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alpha.holgerlevsen.de Received: from alpha.holgerlevsen.de ([62.201.164.66]) by localhost (mail.holgerlevsen.de [62.201.164.66]) (amavisd-new, port 10024) with ESMTP id ex2aKHswQF_z; Wed, 17 Jun 2015 11:39:19 +0200 (CEST) Received: from matrix.localnet (epsilon.holgerlevsen.de [62.201.164.82]) by alpha.holgerlevsen.de (Postfix) with ESMTP id 1A785CAD089; Wed, 17 Jun 2015 11:39:19 +0200 (CEST) From: Holger Levsen To: reproducible-builds@lists.alioth.debian.org, freebsd-hackers@freebsd.org Subject: Re: [Reproducible-builds] reproducible builds of FreeBSD in a chroot on Linux Date: Wed, 17 Jun 2015 11:38:39 +0200 User-Agent: KMail/1.13.7 (Linux/3.16.0-0.bpo.4-amd64; KDE/4.8.4; x86_64; ; ) References: <201505071122.36037.holger@layer-acht.org> <201506162350.11646.holger@layer-acht.org> <387AA935-C074-4F95-A465-E525F7F0E188@cederstrand.dk> In-Reply-To: <387AA935-C074-4F95-A465-E525F7F0E188@cederstrand.dk> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4835019.hJprKGSLqn"; protocol="application/pgp-signature"; micalg=pgp-sha512 Content-Transfer-Encoding: 7bit Message-Id: <201506171138.41932.holger@layer-acht.org> X-Mailman-Approved-At: Wed, 17 Jun 2015 15:01:09 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2015 13:17:51 -0000 --nextPart4835019.hJprKGSLqn Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Erik, On Mittwoch, 17. Juni 2015, Erik Cederstrand wrote: > The build should be immune to the time of the build, of course. That's > fairly easy (e.g. use 'ar -D' consistently and leave DEBUG_FLAGS empty). yup, easy, but this can mean some work. (Which usually can be shared among = the=20 upstream software projects.) =20 > But what about the user who started the build? This leaks to at least > sendmail config files. yup, those are bugs which need to be fixed. (it's also a privacy issue.) > Being agnostic to the path to the src root (e.g. /usr/src or > /home/erik/freebsd/HEAD/src) requires rewriting the compiler __FILE__ > macro to insert a relative path, and make debuggers understand relative > paths. This is hard. while doing this for Debian we haven't found a way to prevent this (leaking= of=20 the build path into build products), so our "solution" now is to use a=20 definited path or record the path and build in the same path again. that is clearly not optimal but currently the only thing we require to be s= ome=20 specific way. > The FreeBSD subversion revision is also leaked several places. That should not matter, as it's part of the source, so it will be the same= =20 revision on rebuilds.=20 > I think reproduce builds are a noble goal and would enable all sorts of > smart analysis, e.g. which binaries are affected by a certain commit. Just > remember to define the requirements that need to be satisfied to get > reproduce builds. sure. *I* also don't plan to fix or even work on FreeBSD, I'm merely=20 investigating it and sharing the results. If the FreeBSD community wants=20 reproducible builds, you will need to work on them ;-) (I'll be happy to help but thats it.) cheers, Holger --nextPart4835019.hJprKGSLqn Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIVAwUAVYFAIQkauFYGmqocAQq1XA/8C3SGL2Ejdp7z3esY6KnAK/WVwN6kjHWI qkKQu+w+7ddJXCTIyEuFrZKJGR6QLefFv4Pu1HHKfMbmxDw67VTzv5S7psdxw1Lw erl4Ys3wuCY23uTTu0OKFi4Szu+s9lA+6YfwFFHIcIo+9mJBLzb4XAVhrBlOV6OS BsrnHAcF0pY1xkO4hg+1U076GMq9mvyLBIWNR4BfY+ymfcS17BPbwls+Lr6XejTm 2Sgz1rfQUlau53uu1gbT/283D4QUPNTKCKKxV3Hxil7WYGqK6nJWanFKD5H4q5b5 VjgYvtM9FlQQ/KnzR75JgnzgzzImKQtcSXWjveX2E1S8FyOuTekq8tWYofOrP5WJ 9dSDgKHCNZBRAJxU1DWQ6LAOx1B2mn8LI8Ln4U/oyW1SgMyjiDBkbg4rhlNT/GTu vMmH9bieqHQVXi2y6BZyADWCggM5n+RLrviBuG69ynjHlO+shQLwtmG8DrTN23Aw Gef+JrmX3DYpZWxAJypaHkEV0Ql9eCMRszdzIQAw+OsrGpOMc/Dc4jmrdUlSfDOP vpEbPsAglbmar0xUHMyrdZY6MS3xu7Uw3q2PM8FTr1Suwo0L+WkA0a5nNAtW4GIG V4T3vrQzkPIXzBgCvMrjvcG3/bwRTmbT/2FqyRkiavFWDmNyUU3AQUXbX18dPByw VC3tmcUMaQg= =lwdG -----END PGP SIGNATURE----- --nextPart4835019.hJprKGSLqn-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 17 16:53:41 2015 Return-Path: Delivered-To: freebsd-hackers@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 934BAD4; Wed, 17 Jun 2015 16:53:41 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1F0E0122; Wed, 17 Jun 2015 16:53:40 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t5HGrVKv076546 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 17 Jun 2015 19:53:31 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t5HGrVKv076546 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t5HGrVPY076545; Wed, 17 Jun 2015 19:53:31 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 17 Jun 2015 19:53:31 +0300 From: Konstantin Belousov To: Andriy Gapon Cc: "freebsd-hackers@freebsd.org" Subject: Re: allow ffs & co. a binary search Message-ID: <20150617165331.GA2080@kib.kiev.ua> References: <20150607081315.7c0f09fb@B85M-HD3-0.alogt.com> <5573EA5E.40806@selasky.org> <20150607195245.62dc191f@B85M-HD3-0.alogt.com> <20150607135453.GH2499@kib.kiev.ua> <558175FA.4040106@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <558175FA.4040106@FreeBSD.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2015 16:53:41 -0000 On Wed, Jun 17, 2015 at 04:28:26PM +0300, Andriy Gapon wrote: > On 07/06/2015 16:54, Konstantin Belousov wrote: > > On Sun, Jun 07, 2015 at 07:52:45PM +0800, Erich Dollansky wrote: > >> What I saw is that all CPUs except ARM uses the software version [of ffs]. > > > > Without quantifiers, this statement is not true. i386 libc function ffs(3) > > uses bsfl instruction to do the job. Compilers know about ffs(3) and friends > > as well, so e.g. gcc 5.1.0 generates the following code for the given > > fragment: > > return (ffs(x) + 1); > > is translated to > > 0: 0f bc c7 bsf %edi,%eax > > 3: ba ff ff ff ff mov $0xffffffff,%edx > > 8: 0f 44 c2 cmove %edx,%eax > > b: 83 c0 02 add $0x2,%eax > > (arg in %edi, result in %eax). > > > > I wrote a patch for amd64 libc long time ago to convert ffs/fls etc to use > > of the bitstring instruction, but Bruce Evans argued that this would be > > excessive. Your patch is excessive for the similar reasons. > > Out of curiosity, what are those (Bruce's) reasons? It is better to ask Bruce. AFAIR it was about 'sufficiently smart compiler' and the fact that the functions are not on the hottest paths. > > > My guess is that significantly clever compiler would recognize a pattern > > used by native ffs implementation and automatically use bitstring > > instructions. E.g., this already happens with popcnt and recent > > gcc/clang, I am just lazy to verify ffs. > > It seems that both clang and gcc are smart enough to replace ffs*() with > __builtin_ffs*() which expand to the corresponding instructions. > On the other hand, neither clang nor gcc has __builtin_fls*() and as far as I > can see neither does anything special for fls*() calls. > > Funny that __builtin_clz is complemented by __builtin_ctz, but there is no > counterpart to __builtin_ffs. > > Lastly, I see no reason to have have different implementations of these > functions for the kernel and userland. Might be, but this is not how things are arranged right now. From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 17 18:24:35 2015 Return-Path: Delivered-To: freebsd-hackers@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0DBE69E1 for ; Wed, 17 Jun 2015 18:24:35 +0000 (UTC) (envelope-from erik+lists@cederstrand.dk) Received: from mailrelay3.public.one.com (mailrelay3.public.one.com [195.47.247.221]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5D5C8DD2 for ; Wed, 17 Jun 2015 18:24:33 +0000 (UTC) (envelope-from erik+lists@cederstrand.dk) X-HalOne-Cookie: 3819c0602baaca470648df44191de22d93e2ac61 X-HalOne-ID: 3df66ac9-14d0-11e5-b2c1-b8ca3afa9d73 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cederstrand.dk; s=20140924; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=k59D4ocLs8Obcii85SQF/qYb1C4Lj2YGgV8MnqOJFZU=; b=IR1AwO1ArZ30lcLUPEPelK1lMLp62JX4DRs7bUlyH8U32S8xOxX3ygCOy2CJIvDsjD5FPc/o/J5QB 3rlvotiVqYYKUfLNXNIscW/9PGf1oakXMK2XmwH9XF1ImVx+BNr2idkipvY0Z1gZt+PoROTlmoH3ti 0WVeu8NSaLz0FJC0= Received: from whopper.router9fbd7c.com (unknown [176.222.238.90]) by smtpfilter1.public.one.com (Halon Mail Gateway) with ESMTPSA; Wed, 17 Jun 2015 09:07:12 +0000 (GMT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: Re: reproducible builds of FreeBSD in a chroot on Linux From: Erik Cederstrand In-Reply-To: <201506162350.11646.holger@layer-acht.org> Date: Wed, 17 Jun 2015 11:07:12 +0200 Cc: freebsd-hackers@freebsd.org, reproducible-builds@lists.alioth.debian.org Content-Transfer-Encoding: quoted-printable Message-Id: <387AA935-C074-4F95-A465-E525F7F0E188@cederstrand.dk> References: <201505071122.36037.holger@layer-acht.org> <554B509B.8020608@fuckner.net> <201506162350.11646.holger@layer-acht.org> To: Holger Levsen X-Mailer: Apple Mail (2.2098) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2015 18:24:35 -0000 > Den 16/06/2015 kl. 23.50 skrev Holger Levsen : >=20 > "Reproducible builds enable anyone to reproduce bit by bit identical = binary=20 > packages from a given source, so that anyone can verify that a given = binary=20 > derived from the source it was said to be derived. " - right now you = have to=20 > *believe* someone that the binary really comes from said source. And = you need=20 > to *believe* the system building it wasn't compromised... The build should be immune to the time of the build, of course. That's = fairly easy (e.g. use 'ar -D' consistently and leave DEBUG_FLAGS empty). But what about the user who started the build? This leaks to at least = sendmail config files. Being agnostic to the path to the src root (e.g. /usr/src or = /home/erik/freebsd/HEAD/src) requires rewriting the compiler __FILE__ = macro to insert a relative path, and make debuggers understand relative = paths. This is hard. The FreeBSD subversion revision is also leaked several places. I think reproduce builds are a noble goal and would enable all sorts of = smart analysis, e.g. which binaries are affected by a certain commit. = Just remember to define the requirements that need to be satisfied to = get reproduce builds. Erik= From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 17 19:07:03 2015 Return-Path: Delivered-To: freebsd-hackers@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 147DAB3C for ; Wed, 17 Jun 2015 19:07:03 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CFAF7B8E for ; Wed, 17 Jun 2015 19:07:02 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: by iebgx4 with SMTP id gx4so40319544ieb.0 for ; Wed, 17 Jun 2015 12:07:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2fIFKWWQ2RPeUZiqnQkhTNGAjPMluSCcqd95OPnvg0E=; b=pi1htNjKa/Or2/tX8g3NMLYbrYwmZpOsbgtRNcg2Y1lD6m14Rf+wFY0wZjhZ3keza0 /AFEz0BvCTgi0B718RsUWtlNUMgbW5uQe7PKi9a+mhCksKzIo4qrhSH2V0/al8Tut6bV L0y5cMIAEUhNKYht1sXppPIfFCnoY4W5z23XDc232K8w/GXdrIHtR8o3Mmv2nOXC6h0H p4G+ebtzX95ejm8xCWpXIV39afnMrY8FwA2TqJNl0KVuIQVutbx9bbOJ0gdSe+hUcvZd 5jV3V1cONLGD2mlENrvHQLdFFdsagUePpXe+oNJwyR+CFP30hvOlIUdcEN+8Lh17z0Zc zhZQ== MIME-Version: 1.0 X-Received: by 10.50.39.105 with SMTP id o9mr37670434igk.39.1434568022181; Wed, 17 Jun 2015 12:07:02 -0700 (PDT) Received: by 10.107.165.16 with HTTP; Wed, 17 Jun 2015 12:07:02 -0700 (PDT) In-Reply-To: References: Date: Wed, 17 Jun 2015 15:07:02 -0400 Message-ID: Subject: Re: PMCSTAT Event for counting L1-DCache Hit / Misses From: Ryan Stone To: Sai Prajeeth Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2015 19:07:03 -0000 On Mon, Jun 15, 2015 at 1:48 PM, Sai Prajeeth wrote: > Hi, > > I am not able to find the event that counts the L1 Data cache hits and > misses in pmccontrol -L. Can anyone tell me what the events are so that i > can get the counts using pmcstat ?\ > > Thanks! > This is specific to your processor model (not just amd64 or armv7, but the model name like "Sandy Bridge" or "Intel E5-2600"). What processor model do you have? It's printed to dmesg and /var/log/messages during boot. From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 17 20:31:42 2015 Return-Path: Delivered-To: freebsd-hackers@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B758CA01 for ; Wed, 17 Jun 2015 20:31:42 +0000 (UTC) (envelope-from csprajeeth@gmail.com) Received: from mail-yh0-x236.google.com (mail-yh0-x236.google.com [IPv6:2607:f8b0:4002:c01::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 742B05FD for ; Wed, 17 Jun 2015 20:31:42 +0000 (UTC) (envelope-from csprajeeth@gmail.com) Received: by yhak3 with SMTP id k3so42338884yha.2 for ; Wed, 17 Jun 2015 13:31:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DsOGAA4EHRrGxs7rMUxmZQy7D2Gqylyh2lpqAZfHn4w=; b=KTTwV2Nqsj8iQbxsxtM/awLn956smzaLBAZJu5BkqDeqOWzlmav/cjulWB+c+LUfeB 5zlv7Um0WQb08ccsGcyrg2GJQH34M0rJoCypfd/twYFqQzTV2mxdVPkdisLgvMU9YiQi Lrw7IczJGDFCypYn3LXYDsCr7wOnDrFoChtBpog1pROPEuD+2X3ZI537xtPjQxmWsYJu oY/tdwigE2S7H8QBBCHukd9ay0ENNJTY6J6qGgDoveWPQwlDYlbdD4Fo++9W2wgt1Oiu psx0G7b2DKhs9VEmXls0MTySAdYLPjp9BsQgJ6iwKAFQxlXK9W6mXAHmL3LWQc/kWYss q0lQ== MIME-Version: 1.0 X-Received: by 10.129.80.4 with SMTP id e4mr9261481ywb.31.1434573101538; Wed, 17 Jun 2015 13:31:41 -0700 (PDT) Received: by 10.37.194.134 with HTTP; Wed, 17 Jun 2015 13:31:41 -0700 (PDT) In-Reply-To: References: Date: Thu, 18 Jun 2015 02:01:41 +0530 Message-ID: Subject: Re: PMCSTAT Event for counting L1-DCache Hit / Misses From: Sai Prajeeth To: Ryan Stone Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2015 20:31:42 -0000 Intel Xeon X5650 2660.05-MHz K8-class CPU. Family = 0x6 Model = 0x2c Stepping = 2. Pretty sure its Intel Nehalem architecture. On Thu, Jun 18, 2015 at 12:37 AM, Ryan Stone wrote: > On Mon, Jun 15, 2015 at 1:48 PM, Sai Prajeeth > wrote: > >> Hi, >> >> I am not able to find the event that counts the L1 Data cache hits and >> misses in pmccontrol -L. Can anyone tell me what the events are so that i >> can get the counts using pmcstat ?\ >> >> Thanks! >> > > This is specific to your processor model (not just amd64 or armv7, but the > model name like "Sandy Bridge" or "Intel E5-2600"). What processor model > do you have? It's printed to dmesg and /var/log/messages during boot. > From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 17 20:48:51 2015 Return-Path: Delivered-To: freebsd-hackers@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A5BA0FB7 for ; Wed, 17 Jun 2015 20:48:51 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6E658945 for ; Wed, 17 Jun 2015 20:48:51 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by igbos3 with SMTP id os3so3084368igb.0 for ; Wed, 17 Jun 2015 13:48:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=WWaehozoauwn0dIM9OeDMrjVXLSkN9vHwWGWidvwQSI=; b=GmbUynOt3e3b6zZLkzFxH2To/IOYDWCrQZIJPwMoLGFaoH+4mY9qWZUh8BLNl+rg8u 5UXKWErnA4jmdCcc3ZF3+qBroOs7//eBmanNdCgoE6BYjK0bOghJutyoUcc08qKs+7YU i7mm+NjG96VWQu1VSDG379TDL7tppSzpxLoixEdtjhn22r0b+HRmX5NsdiIKxmBPSkcd U9ZG++B2eDLtpMrMHYkybs25E6IhC/aj6LvmzOLiObEaxybUlirGRCLMpckV7VZEt2ME Tb7EynmBs7EK60UN9GcapheJgHxCE2HIlTgV2v1cBzyvvaDJuMKpOE7AKGe0ksJzUWqA ke1Q== X-Received: by 10.43.12.136 with SMTP id pi8mr2298347icb.6.1434574130837; Wed, 17 Jun 2015 13:48:50 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.48.3 with HTTP; Wed, 17 Jun 2015 13:48:30 -0700 (PDT) In-Reply-To: <201506162350.11646.holger@layer-acht.org> References: <201505071122.36037.holger@layer-acht.org> <554B509B.8020608@fuckner.net> <201506162350.11646.holger@layer-acht.org> From: Ed Maste Date: Wed, 17 Jun 2015 16:48:30 -0400 X-Google-Sender-Auth: 0U5b6hjvja4KbpjRuc6-1HkDdco Message-ID: Subject: Re: reproducible builds of FreeBSD in a chroot on Linux To: Holger Levsen Cc: "freebsd-hackers@freebsd.org" , reproducible-builds@lists.alioth.debian.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2015 20:48:51 -0000 On 16 June 2015 at 17:50, Holger Levsen wrote: > > So in a while, I expect to have set up > https://reproducible.debian.net/freebsd/ as well as > https://reproducible.debian.net/netbsd/ - but no promises (yet), but these are > my plans ;-) Great, looking forward to it! > https://wiki.freebsd.org/ReproducibleBuilds claims there are 3 known issues > (for "make world" AIUI) for HEAD, I would like to build twice and verify > myself. I'm interested in fixing the remaining kernel / world issues, with the kernel being my higher priority. For the kernel we have the username, hostname, and build timestamp. The path is included too, but I don't anticipate trying to address it at first; release builds are done in a consistent location anyhow (/usr/src). These are used only as user-facing strings for the kern.version sysctl and reported by uname. An example kern.version string: FreeBSD 10.1-STABLE #28 r280427+86df2de(stable-10): Thu Mar 26 16:07:47 EDT 2015 emaste@feynman:/tank/emaste/obj/tank/emaste/src/git-stable-10/sys/GENERIC >From a technical perspective they're trivially eliminated. There may be some 3rd party ports expect the precise format, but probably not very many (and they should be fixed, anyhow). There's a much larger social issue in convincing the FreeBSD developer community to accept their removal, though :-) > https://wiki.freebsd.org/PortsReproducibleBuilds says "Of the 23599 packages > which were built in both runs, 15164 have the same checksum when using the > previously mentioned patch, giving 64.25% reproducible packages." - I'm also > curious to re-confirm this - and set up a test bed, which can be triggered > regularily and easily. Our jenkins set up allows this and I'm interested to do > this. I'm pleasantly surprised by the ports results -- 64.25% seems quite good for such a straightforward change. The test there is on the same host though, and so avoids any non-reproducibility from host/user/path leaks. > My interest is to help FreeBSD with reproducible builds as I want to see > reproducible builds become the norm in the free software world and as I > believe FreeBSD is an important part of this world. And also because I'm > curious. :) Great! Hopefully we can help lend some weight in convincing upstream projects to accept reproducibility patches (once we get further along in our ports effort). -Ed From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 17 20:57:52 2015 Return-Path: Delivered-To: freebsd-hackers@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 96283268 for ; Wed, 17 Jun 2015 20:57:52 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5CF94BB3 for ; Wed, 17 Jun 2015 20:57:52 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: by igbos3 with SMTP id os3so3256347igb.0 for ; Wed, 17 Jun 2015 13:57:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZvNCvLa325unlw3SDKWXu+sQfI5Ym5HDc5kDed5o49U=; b=PfFaKppqTXk2UcD04OdqoEhOQk1YkntKrSBPjldPtTw8qvMpEzOjZui43h448mPsG9 oQLpk7Zu7ZjZqSNcHiAesX2HycYpHdpA7xykAd7Z6t7/Zoith3EVahzV3mqk9MzASjuc 1lwRATqz49sweAQS0AxU0cq5RdnfpRBM+ep0wnYWGkeQBjS65J0oE5mC3idcorn3BMJD IGcDPBPQKSrCBF6n0c3jKmmWXGy1/Xgb0mgyUNUVwz5hpl/r60pf22eAzp+QQtA8g0WD 3e78MzQXz15s/QzZO9boSP9EG3wW5H8aJf+x7wQlwmO7ISO7LLyHAeQqUbVIFxLEkFjP qKMA== MIME-Version: 1.0 X-Received: by 10.107.129.82 with SMTP id c79mr10660605iod.87.1434574671702; Wed, 17 Jun 2015 13:57:51 -0700 (PDT) Received: by 10.107.165.16 with HTTP; Wed, 17 Jun 2015 13:57:51 -0700 (PDT) In-Reply-To: References: Date: Wed, 17 Jun 2015 16:57:51 -0400 Message-ID: Subject: Re: PMCSTAT Event for counting L1-DCache Hit / Misses From: Ryan Stone To: Sai Prajeeth Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2015 20:57:52 -0000 On Wed, Jun 17, 2015 at 4:31 PM, Sai Prajeeth wrote: > Intel Xeon X5650 2660.05-MHz K8-class CPU. Family = 0x6 Model = 0x2c > Stepping = 2. > > Pretty sure its Intel Nehalem architecture. > Googling seems to indicate this this is a Westmere, although Intel's site could be much clearer (and really, so could hwpmc -- there should be a sysctl telling you what manpage to look at). If it is Westmere, the manpage is here: https://www.freebsd.org/cgi/man.cgi?query=pmc.westmere&apropos=0&sektion=0&manpath=FreeBSD%209.0-RELEASE&arch=default&format=html These counters are probably what you're looking for. Summing up everything but the L1D_HIT counter should give you the number of misses. It would be nice if hwpmc had a L1D_MISS counter using a umask of 0x5E, which sum things up automatically for you. MEM_LOAD_RETIRED.L1D_HIT (Event CBH, Umask 01H) Counts number of retired loads that hit the L1 data cache. MEM_LOAD_RETIRED.L2_HIT (Event CBH, Umask 02H) Counts number of retired loads that hit the L2 data cache. MEM_LOAD_RETIRED.L3_UNSHARED_HIT (Event CBH, Umask 04H) Counts number of retired loads that hit their own, unshared lines in the L3 cache. MEM_LOAD_RETIRED.OTHER_CORE_L2_HIT_HITM (Event CBH, Umask 08H) Counts number of retired loads that hit in a sibling core's L2 (on die core). Since the L3 is inclusive of all cores on the package, this is an L3 hit. This counts both clean or modified hits. MEM_LOAD_RETIRED.L3_MISS (Event CBH, Umask 10H) Counts number of retired loads that miss the L3 cache. The load was satisfied by a remote socket, local memory or an IOH. MEM_LOAD_RETIRED.HIT_LFB (Event CBH, Umask 40H) Counts number of retired loads that miss the L1D and the address is located in an allocated line fill buffer and will soon be committed to cache. This is counting sec- ondary L1D misses. From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 18 13:52:44 2015 Return-Path: Delivered-To: freebsd-hackers@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 762CBF42 for ; Thu, 18 Jun 2015 13:52:44 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id A905261F for ; Thu, 18 Jun 2015 13:52:43 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA16810; Thu, 18 Jun 2015 16:52:41 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Z5aFF-000DQz-6r; Thu, 18 Jun 2015 16:52:41 +0300 Message-ID: <5582CCF1.8010505@FreeBSD.org> Date: Thu, 18 Jun 2015 16:51:45 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Konstantin Belousov CC: "freebsd-hackers@freebsd.org" Subject: Re: allow ffs & co. a binary search References: <20150607081315.7c0f09fb@B85M-HD3-0.alogt.com> <5573EA5E.40806@selasky.org> <20150607195245.62dc191f@B85M-HD3-0.alogt.com> <20150607135453.GH2499@kib.kiev.ua> <558175FA.4040106@FreeBSD.org> <20150617165331.GA2080@kib.kiev.ua> In-Reply-To: <20150617165331.GA2080@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2015 13:52:44 -0000 On 17/06/2015 19:53, Konstantin Belousov wrote: > AFAIR it was about 'sufficiently smart compiler' and the fact that the > functions are not on the hottest paths. It seems that sufficiently smart compilers still do not exist :-) At least as far as compilers that are used for compiling FreeBSD are considered. [Offtopic] my impression is that lately smartness of compilers is mostly being improved by various tricks and shortcuts (undefined behavior, etc), rather than by recognizing patterns in the C code that could be turned into more efficient machine code. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 19 13:12:06 2015 Return-Path: Delivered-To: freebsd-hackers@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9E2CF957 for ; Fri, 19 Jun 2015 13:12:06 +0000 (UTC) (envelope-from cmfitch1@gmail.com) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 69748773 for ; Fri, 19 Jun 2015 13:12:06 +0000 (UTC) (envelope-from cmfitch1@gmail.com) Received: by igbqq3 with SMTP id qq3so15408176igb.0 for ; Fri, 19 Jun 2015 06:12:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=eQhTapPSPNY6Nnvw4rLhcHL03MwOJ5hHe+DWjIfE0GQ=; b=L6gE+7VzXVit9rLhEO5SenMU3uX5pbww2Dn3fy4L/Kg/SU2MfPgDfu8kDXk6Iw/d1Z DDgjpsRLQetkHd6OhdSu8fkUZhXpM2lU36JtzqpScQvOCmol0unVaOvHdVrqyTbaalto umnrXkXxOcJqB/cXuCcssvQmZCJqzIuQU1DIoT6FFAFaXFU78rxeXlJUsNolbmjI6AIm +t6PLRvGx6sVK/DNQVhda4Vca8FLOlSEl8f8NLPmGMLFwKOB3/oz71f6oINHJuuzWqoa T1CUMXN5XTgEeoe8AaTOnDbpodRN7Rsq15NccYMpvJ5nuFgYrvQvRlETKnWjtTdk97Jg dcRg== MIME-Version: 1.0 X-Received: by 10.107.170.216 with SMTP id g85mr14024438ioj.31.1434719525684; Fri, 19 Jun 2015 06:12:05 -0700 (PDT) Received: by 10.79.113.27 with HTTP; Fri, 19 Jun 2015 06:12:05 -0700 (PDT) Date: Fri, 19 Jun 2015 09:12:05 -0400 Message-ID: Subject: Realtime process CPU starvation From: Chris Fitch To: freebsd-hackers@freebsd.org X-Mailman-Approved-At: Fri, 19 Jun 2015 13:25:10 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2015 13:12:06 -0000 Hello all, I have a problem that appears to be scheduler/filesystem related and could use some expert advice. I have a process running at realtime priority 0 under FreeBSD 10.0. The main thread needs to run every 10 ms, and when it has completed its work, it yields the processor via a nanosleep() call. The sleep time is computed to be the remainder of the 10 ms period that is not needed. This mostly works, but there are occurrences where the thread doesn't run again for an extended period of time. The thread is monitoring how far behind the realtime target it is and reporting whenever it falls more than 250 ms behind. I have seen it report anywhere from 270 ms to almost 2 seconds behind. This was confirmed using an off-cpu dtrace script with the following results when the thread reported that it fell 500 ms behind: Off cpu times (milliseconds): process value ------------- Distribution ------------- count -1 | 0 0 | 18 1 | 1 2 | 5 4 | 12 8 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 42229 16 | 7 32 | 7 64 | 0 128 | 3 256 | 1 512 | 0 How can a thread with the highest realtime priority not run for such a lengthy period? I dove into the ULE scheduler, and although I was in a bit over my head, it seems to me that the only way this is possible is for kernel priority threads to be starving it of CPU. I tried decreasing kern.sched.slice to 3 hoping that smaller scheduler timeslices would decrease the wait time if several kernel threads were ahead of it in the run queue, but it didn't help. I was suspicious of the ZFS filesystem, as the delayed running of the thread seemed to coincide with short periods of moderate disk activity. I obtained some evidence to confirm my suspicions using KTR_SCHED and schedgraph.py. The trace shows that 'solthread 0xfffffff' was running for almost 500 ms when the problem occurred. During this 500 ms, two of the four CPUs were idle. Based on the graph, it appears that an OpenSolaris thread can starve a realtime process of CPU when idle CPUs are available. Any thoughts? Thanks, Chris From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 19 16:03:07 2015 Return-Path: Delivered-To: freebsd-hackers@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 53B7FC80 for ; Fri, 19 Jun 2015 16:03:07 +0000 (UTC) (envelope-from brandon@brandonvalentine.com) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 271D182F for ; Fri, 19 Jun 2015 16:03:06 +0000 (UTC) (envelope-from brandon@brandonvalentine.com) Received: by iebmu5 with SMTP id mu5so77675415ieb.1 for ; Fri, 19 Jun 2015 09:03:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=9RkQeklKfA16j10+NrBnO+PSIsxLYbA5+qcbLBDmz7g=; b=eplT0JGUX7mLjUy5fuQxJ0kucSLtVL7Vd8el0HWLDZBXtPv8IeaFEwOAzeSny4Mswu pkhUsrvR2p1JIdAXASqn2marqgpW1AzOCNOFGpo0cNMGWn3qleH4U96RaycloPnXQJh5 zGpeDnad0WLe/3AfzqDSgPU23a8yF0rEvkT1l1vZs9uXXhRGGPo81MKiJHPQdmwL4SpN /qDUcHkn5ODTBUvLMM6fm4EGS7UovlOmQnl/Dop9lu/hVtYU1MFFH/atUSJB417xxgAF kNkqLfwOREC9IdenUgm2q7iqh8C/6kgzGH9K06bqj7V7oEjCAiqyUriLwnCAEt0fKUdw ppvA== X-Gm-Message-State: ALoCoQl4vXHxYeZb51ZG28arNXwLCfoex8mjC6VVvVLcgz8wGjm8fqf9eaZfg7rDaie5CDi8bYE+ MIME-Version: 1.0 X-Received: by 10.42.226.8 with SMTP id iu8mr12480435icb.17.1434729780128; Fri, 19 Jun 2015 09:03:00 -0700 (PDT) Received: by 10.64.154.199 with HTTP; Fri, 19 Jun 2015 09:03:00 -0700 (PDT) Date: Fri, 19 Jun 2015 11:03:00 -0500 Message-ID: Subject: debugging ATA command timeouts on 10.1-RELEASE From: Brandon Valentine To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2015 16:03:07 -0000 [ Starting with -hackers before a possible PR. If there's a better place for this thread please advise. ] Howdy, I have an older Soekris net4801 with a NatSemi SC1100 ATA chipset. Runs great under FreeBSD 8.3, but 10.1-RELEASE-p13 spews the following error, in a loop, upon boot: (aprobe0:ata0:0:1:0): ATA_IDENTIFY. ACB: ec 00 00 00 00 40 00 00 00 00 00 00 (aprobe0:ata0:0:1:0): CAM status: Command timeout (aprobe0:ata0:0:1:0): Retrying command The atapci driver recognizes it as: atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xe000-0xe00f at device 18.2 on pci0 And eventually, after a lot of command timeouts, I will get: ada0: 16.700MB/s transfers (PIO4, PIO 512bytes) ada0: 3825MB (7835184 512 byte sectors: 16H 63S/T 7773C) ada0: Previously was known as ad0 However, the system continues issuing failed ATA_IDENTIFY commands after this and never succeeds in booting. That ada device being detected there is a 4GB CompactFlash card. In order to eliminate the possibility that the hardware or card do not support UDMA, write caching, etc, I am booting this 10.1-RELEASE-p13 kernel with the following kernel hints in loader.conf: hint.ata.0.mode="PIO4" hint.ata.1.mode="PIO4" hint.ahci.0.msi="0" hint.atapci.0.msi="0" hint.acpi.0.disabled="1" kern.cam.ada.write_cache="0" Removing these hints does not make any difference in the outcome. It has been a while but I'm no stranger to -hackers or this sort of debugging, but I'm wholly unfamiliar with the CAM subsystem. I've compiled and booted a 10.1-RELEASE-p13 kernel with all CAM debug flags enabled and the complete debug log of a boot attempt can be seen here: https://gist.github.com/bval/0ab616a57b2846f633ab Is there a developer more familiar with CAM who can take a look at this and advise me on what might be happening or where to go next in debugging this? I'm willing to do the legwork just need some guidance. Thanks, Brandon -- Brandon D. Valentine http://www.brandonvalentine.com From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 20 00:10:14 2015 Return-Path: Delivered-To: freebsd-hackers@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 69B32E1C for ; Sat, 20 Jun 2015 00:10:14 +0000 (UTC) (envelope-from dieterbsd@gmail.com) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3834ACCD for ; Sat, 20 Jun 2015 00:10:14 +0000 (UTC) (envelope-from dieterbsd@gmail.com) Received: by igblz2 with SMTP id lz2so23330085igb.1 for ; Fri, 19 Jun 2015 17:10:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=tYd80MZg2nQiRBS7Rboxu5PafQ9jJpdPtxnjqdDXLnk=; b=qborA2zjW5MK67tQqIUz8IwjmSkOL22vKEjyvpwFwsV0s0vcflbtI/ntkOtM+xy5Mj z62yJ+4cXdafIXxCVJB5K80PXU12K4WFc3cX8kle4uoJhZcYPG6rL37kqTklIwJLdGGW cxvYlTJfIvzE3SAmz2Abl3UKS/b4LfkPVCsCB96tvTiZLgF2gsQuj8T1SVHB8xNJeYuR ZFskP7uwCTJvWk8NIZOowfE6vMXseNmnn6HJajq3Xe4egfFoEI+Dn1ciHiVaLCjA/MbP 6W2uIoUmFMQyERV4l+gkdhqQvP8yi3wBS9MLH1L1CTyXgKEW5Vkhgu+6ZUVBYSnH3Cvs fIyg== MIME-Version: 1.0 X-Received: by 10.42.113.133 with SMTP id c5mr14777369icq.67.1434759011928; Fri, 19 Jun 2015 17:10:11 -0700 (PDT) Received: by 10.64.2.132 with HTTP; Fri, 19 Jun 2015 17:10:11 -0700 (PDT) Date: Fri, 19 Jun 2015 17:10:11 -0700 Message-ID: Subject: Re: Realtime process CPU starvation From: Dieter BSD To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jun 2015 00:10:14 -0000 Chris typed: > I have a process running at realtime priority 0 > under FreeBSD 10.0. The main thread needs to run every 10 ms, #include FreeBSD is not a true real time OS. Please submit your patch to make it one. > How can a thread with the highest realtime priority not run for such a > lengthy period? Some device drivers do things like for(ever) { DELAY(MAXINT); } which does wonders for true-real-time jobs. :-( (and sucks even for non-real-time jobs) I have also found that kernel printf(9) can spoil true-real-time jobs. Hint: log(9) is your friend. I run a lot of true-real-time jobs (needs something like < 4ms) on a uniprocessor, and most of the time they run fine. Even running several of these jobs at once. Carefully crafted userland program running at rtprio 5. It took a *lot* of work finding the problems and a lot of kernel hacking (mostly device drivers) to get this far. This is with 8.2. Tried 10.1 but it is severly broken (in non-real-time-ways) and is unusable. :-( But even now I still get a true-real-time failure occasionally (and data lost forever :-( ) and no clue why. :-( > ULE scheduler Has problems. I frequently run jobs that should be either cpu-bound or disk-bound, but observe a significant percentage of cpu idle time *and* the disk i/o rate is far lower than it should be. No clue what is going on there. Fortunately these jobs are not true-real-time. I guess I'll have to call these jobs "scheduler-bound". > I was suspicious of the ZFS filesystem How much grief would it be to try a different filesystem (e.g. FFS)? (I run FFS with softdep.) > During this 500 ms, two of the four CPUs were idle. Hmmm, could the scheduler be trying to always run your true-real-time job on the same cpu and it is waiting for that cpu to become free? Is there a way to ask the scheduler to run your rt job on cpu0 and zfs on cpu1? That might help rule zfs in or out as a problem. (Clearly I am not a scheduler wizard.) Maybe see if there is a way to instrument the scheduler without having the instrumentation creating its own rt or scheduling problem? From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 20 06:56:20 2015 Return-Path: Delivered-To: freebsd-hackers@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 18709E8F for ; Sat, 20 Jun 2015 06:56:20 +0000 (UTC) (envelope-from hans@beastielabs.net) Received: from testsoekris.hotsoft.nl (unknown [IPv6:2001:888:1227:0:200:24ff:fec9:5934]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C81787D6 for ; Sat, 20 Jun 2015 06:56:19 +0000 (UTC) (envelope-from hans@beastielabs.net) Received: from beastie.hotsoft.nl (beastie.hotsoft.nl [IPv6:2001:888:1227:0:219:d1ff:fee8:91eb]) by testsoekris.hotsoft.nl (8.14.7/8.14.7) with ESMTP id t5K6uCLk009038; Sat, 20 Jun 2015 08:56:12 +0200 (CEST) (envelope-from hans@beastielabs.net) Message-ID: <55850E78.3040600@beastielabs.net> Date: Sat, 20 Jun 2015 08:55:52 +0200 From: Hans Ottevanger User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Brandon Valentine CC: freebsd-hackers@freebsd.org Subject: Re: debugging ATA command timeouts on 10.1-RELEASE References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jun 2015 06:56:20 -0000 On 06/19/15 18:03, Brandon Valentine wrote: > [ Starting with -hackers before a possible PR. If there's a better place > for this thread please advise. ] > > Howdy, > > I have an older Soekris net4801 with a NatSemi SC1100 ATA chipset. Runs > great under FreeBSD 8.3, but 10.1-RELEASE-p13 spews the following error, in > a loop, upon boot: > > (aprobe0:ata0:0:1:0): ATA_IDENTIFY. ACB: ec 00 00 00 00 40 00 00 00 00 00 00 > (aprobe0:ata0:0:1:0): CAM status: Command timeout > (aprobe0:ata0:0:1:0): Retrying command > > The atapci driver recognizes it as: > > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xe000-0xe00f at device 18.2 on pci0 > > And eventually, after a lot of command timeouts, I will get: > > ada0: 16.700MB/s transfers (PIO4, PIO 512bytes) > ada0: 3825MB (7835184 512 byte sectors: 16H 63S/T 7773C) > ada0: Previously was known as ad0 > > However, the system continues issuing failed ATA_IDENTIFY commands after > this and never succeeds in booting. That ada device being detected there is > a 4GB CompactFlash card. In order to eliminate the possibility that the > hardware or card do not support UDMA, write caching, etc, I am booting this > 10.1-RELEASE-p13 kernel with the following kernel hints in loader.conf: > > hint.ata.0.mode="PIO4" > hint.ata.1.mode="PIO4" > hint.ahci.0.msi="0" > hint.atapci.0.msi="0" > hint.acpi.0.disabled="1" > kern.cam.ada.write_cache="0" > > Removing these hints does not make any difference in the outcome. > > It has been a while but I'm no stranger to -hackers or this sort of > debugging, but I'm wholly unfamiliar with the CAM subsystem. I've compiled > and booted a 10.1-RELEASE-p13 kernel with all CAM debug flags enabled and > the complete debug log of a boot attempt can be seen here: > > https://gist.github.com/bval/0ab616a57b2846f633ab > > Is there a developer more familiar with CAM who can take a look at this and > advise me on what might be happening or where to go next in debugging this? > I'm willing to do the legwork just need some guidance. > The oldest Soekris 4801 boards that I have indeed do not support UDMA. I have always used this in /boot/loader.conf: hw.ata.ata_dma="0" to prevent issues like you describe. My systems are now at 10.1-STABLE. Kind regards, Hans Ottevanger Eindhoven, Netherlands www.beastielabs.net From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 20 07:19:52 2015 Return-Path: Delivered-To: freebsd-hackers@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AA5EE256; Sat, 20 Jun 2015 07:19:52 +0000 (UTC) (envelope-from ps06756@gmail.com) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 37D92C1D; Sat, 20 Jun 2015 07:19:52 +0000 (UTC) (envelope-from ps06756@gmail.com) Received: by lacny3 with SMTP id ny3so85422058lac.3; Sat, 20 Jun 2015 00:19:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=R+BNE4OCSTWmdvounUL0LNzM17qviEHsArs0ZmRPSDY=; b=tFbL01DFB1G+dnXbIp0sHfEXHK9dq6Rm/Nxwcycyaq62Gj1hfKEztP225OXNBdSwXE 5gp8S10xHqjCcv6pHeLwH3JjMrBOaGzMQfmthajhHMfgHpjZf2u/cqYWSFHdr6LL4uP1 A/hpIHT/orrAkYBfCT6cWARBHMpcYFo+coMzYy9Y5wP5Np+/UCNX48LNwY2PWSww5RT8 Dd2sspZRtQz+wemQJLk8Cr4ULej2vvmxOzFMUL6ke9kwvdRYTJIze1JvRQ1z3OkfOfUD dFeANo91azpBTl7ED0Gb/TWRVO1WFp5GJpw0gEQeHKMLQ5eYG2WbkcZLHgztz4T8lHYF t3jQ== X-Received: by 10.112.42.16 with SMTP id j16mr20767919lbl.98.1434784790179; Sat, 20 Jun 2015 00:19:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.61.199 with HTTP; Sat, 20 Jun 2015 00:19:29 -0700 (PDT) From: Pratik Singhal Date: Sat, 20 Jun 2015 12:49:29 +0530 Message-ID: Subject: How to test for memory corruption ? To: freebsd-hackers , FreeBSD Questions Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jun 2015 07:19:52 -0000 Hello, I have written code for adding support for DMA transfers for Allwinner A10 SoC (Cubieboard 1) in MMC driver/ I have tried transferring files to/from mmc card and verified that files are copied fine. Although, many times the kernel panics suddenly, after I transfer files. This does not happen If I use PIO to transfer data (PIO's code is tested and already committed to ~HEAD). Panics don't occur in the statements written for DMA transfer. I am suspecting that the problem is that the DMA transfer apart from writing where it is required, is overwriting other parts of the memory also. Is there any way, I can verify that this is/this is not the case ? Thank you, Pratik Singhal From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 20 18:20:39 2015 Return-Path: Delivered-To: freebsd-hackers@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5002A9AB for ; Sat, 20 Jun 2015 18:20:39 +0000 (UTC) (envelope-from dieterbsd@gmail.com) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1DB0B80E for ; Sat, 20 Jun 2015 18:20:39 +0000 (UTC) (envelope-from dieterbsd@gmail.com) Received: by igblr2 with SMTP id lr2so11100291igb.0 for ; Sat, 20 Jun 2015 11:20:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=5zmNCg4EgcAIykd5ly4ypBt/1aaOQUwlT7+GtwAW2n8=; b=EdMzCvqkx6OgxwD9SAYKbRp8E+aLQSIhuo6gs5be5Y9mXOuVaSv92qiA/nNUKHIBqQ EhFMCYHrlwJ/n0iZu9sUqJvv84ojLN+62c0R4+z7MDbmbPtvdxSdkigd/5VCZV9ak1F6 am1coJnXdUx07owtINeCrlfu6vR5bEgqgxhONssAVL24PKUGFWtvFLoMgxZID6IFzIiP T+25II2auLUDPbfZJ2flxs/PizXLrUl1VuQ0365/XhY/etJsJdeUmDzL6b9Ob70aci15 Ex3pwD0R21HQsWtuLuDIyAPF5hKjkZLZ8SCzfYg2JnniywshEXH3HlqGOVrhR256qzwh AJbQ== MIME-Version: 1.0 X-Received: by 10.43.169.137 with SMTP id nm9mr17731708icc.82.1434824438408; Sat, 20 Jun 2015 11:20:38 -0700 (PDT) Received: by 10.64.2.132 with HTTP; Sat, 20 Jun 2015 11:20:38 -0700 (PDT) Date: Sat, 20 Jun 2015 11:20:38 -0700 Message-ID: Subject: Re: Realtime process CPU starvation From: Dieter BSD To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jun 2015 18:20:39 -0000 For those who care, I'm running kern.sched.name: ULE My (feeble) understanding is that the scheduler mostly looks at cpu time, and processes doing i/o actually get a bump *up* in priority, since because of the way hardware worked in the late 1970s-early 1980s (PDP-11, VAX, ...) the i/o got useful work done while using very little cpu time. As a result, jobs that do a lot of i/o can receive more than their fair share of cpu time. And nice(1) (even rtprio and idprio) may not have much effect on jobs that are i/o bound. Some form of ionice is sorely needed. From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 20 19:23:58 2015 Return-Path: Delivered-To: freebsd-hackers@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9896FE16 for ; Sat, 20 Jun 2015 19:23:58 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5303D8E3 for ; Sat, 20 Jun 2015 19:23:58 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1Z6Nuz-0002Aa-RL; Sat, 20 Jun 2015 21:55:05 +0300 Date: Sat, 20 Jun 2015 21:55:05 +0300 From: Slawa Olhovchenkov To: Dieter BSD Cc: freebsd-hackers@freebsd.org Subject: Re: Realtime process CPU starvation Message-ID: <20150620185505.GA1647@zxy.spb.ru> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jun 2015 19:23:58 -0000 On Fri, Jun 19, 2015 at 05:10:11PM -0700, Dieter BSD wrote: > Chris typed: > > I have a process running at realtime priority 0 > > under FreeBSD 10.0. The main thread needs to run every 10 ms, > > #include > FreeBSD is not a true real time OS. Please submit your patch > to make it one. For make it one first need develop and enforce some policy for drivers and programs. For exmample, RT-11 declare "A good guideline is to spend no more than 50 microseconds at priority 7". Also, need new disk i/o subsystem, for try async disk i/o (currently disk i/o is synchronys for many operations like open, close, rename, mkdir, delete) and allowing abort and cancel all i/o operations.