From owner-freebsd-hackers@freebsd.org Mon Aug 21 04:44:05 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8B51DDE7714 for ; Mon, 21 Aug 2017 04:44:05 +0000 (UTC) (envelope-from j.deboynepollard-newsgroups@ntlworld.com) Received: from know-smtprelay-omc-2.server.virginmedia.net (know-smtprelay-omc-2.server.virginmedia.net [80.0.253.66]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Bizanga Labs SMTP Client Certificate", Issuer "Bizanga Labs CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 01DD18490B for ; Mon, 21 Aug 2017 04:44:04 +0000 (UTC) (envelope-from j.deboynepollard-newsgroups@ntlworld.com) Received: from [192.168.1.5] ([86.10.211.13]) by know-smtprelay-2-imp with bizsmtp id zgir1v0040HtmFq01girjN; Mon, 21 Aug 2017 05:42:51 +0100 X-Originating-IP: [86.10.211.13] X-Authenticated-User: J.deBoynePollard-newsgroups@NTLWorld.COM X-Spam: 0 X-Authority: v=2.1 cv=ELn7qAtC c=1 sm=1 tr=0 a=SB7hr1IvJSWWr45F2gQiKw==:117 a=SB7hr1IvJSWWr45F2gQiKw==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=x7bEGLp0ZPQA:10 a=eG1FbsFRfBOjMoeD4h0A:9 a=QEXdDO2ut3YA:10 To: FreeBSD Hackers From: Jonathan de Boyne Pollard Subject: Re: `ifconfig` patch to resolve IPv6 scope names Message-ID: <598333dc-dd80-af14-98b9-0ee7b4eea6e9@NTLWorld.COM> Date: Mon, 21 Aug 2017 05:42:51 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 04:44:05 -0000 raichoo: > + switch (__IPV6_ADDR_MC_SCOPE(addr)) { > > + case __IPV6_ADDR_SCOPE_NODELOCAL: > I recommend instead using IN6_IS_ADDR_MC_NODELOCAL() and its ilk from netinet/in.h . They are defined by the SUS. From owner-freebsd-hackers@freebsd.org Wed Aug 23 01:10:22 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C7DCEDCB1AE for ; Wed, 23 Aug 2017 01:10:22 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id B055580930 for ; Wed, 23 Aug 2017 01:10:22 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from yv.noip.me (c-24-6-186-56.hsd1.ca.comcast.net [24.6.186.56]) (authenticated bits=0) by shell1.rawbw.com (8.15.1/8.15.1) with ESMTPSA id v7N1AF2F084752 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 22 Aug 2017 18:10:16 -0700 (PDT) (envelope-from yuri@rawbw.com) X-Authentication-Warning: shell1.rawbw.com: Host c-24-6-186-56.hsd1.ca.comcast.net [24.6.186.56] claimed to be yv.noip.me Subject: Re: How can the shared memory object be undeletable when all shared memory segments belong to the same user? To: Konstantin Belousov Cc: Freebsd hackers list References: <20170812090308.GH1700@kib.kiev.ua> From: Yuri Message-ID: Date: Tue, 22 Aug 2017 18:10:14 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170812090308.GH1700@kib.kiev.ua> Content-Language: en-US Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2017 01:10:22 -0000 On 08/12/17 02:03, Konstantin Belousov wrote: >> Only renaming of the shared memory object in the code or reboot helped. > Root should be able to unlink it. Isn't shared memory supposed to be deleted when the last app that used it quits, gracefully or not? Yuri From owner-freebsd-hackers@freebsd.org Wed Aug 23 06:49:57 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 98D12DDFEE5 for ; Wed, 23 Aug 2017 06:49:57 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1EC0A649EE for ; Wed, 23 Aug 2017 06:49:56 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v7N6nprk057293 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 23 Aug 2017 09:49:52 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v7N6nprk057293 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v7N6nou6057292; Wed, 23 Aug 2017 09:49:50 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 23 Aug 2017 09:49:50 +0300 From: Konstantin Belousov To: Yuri Cc: Freebsd hackers list Subject: Re: How can the shared memory object be undeletable when all shared memory segments belong to the same user? Message-ID: <20170823064950.GM1700@kib.kiev.ua> References: <20170812090308.GH1700@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2017 06:49:57 -0000 On Tue, Aug 22, 2017 at 06:10:14PM -0700, Yuri wrote: > On 08/12/17 02:03, Konstantin Belousov wrote: > >> Only renaming of the shared memory object in the code or reboot helped. > > Root should be able to unlink it. > > > Isn't shared memory supposed to be deleted when the last app that used > it quits, gracefully or not? Yes for anonymous, no for named. From owner-freebsd-hackers@freebsd.org Wed Aug 23 21:29:09 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E4570DEF3F6 for ; Wed, 23 Aug 2017 21:29:09 +0000 (UTC) (envelope-from fernando.apesteguia@gmail.com) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (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 7337A82453 for ; Wed, 23 Aug 2017 21:29:09 +0000 (UTC) (envelope-from fernando.apesteguia@gmail.com) Received: by mail-lf0-x234.google.com with SMTP id y15so5793513lfd.5 for ; Wed, 23 Aug 2017 14:29:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=FL6m6bT9anjEz6psN8S7zWl6/18GHOiSiimnRAHRM5Y=; b=UMXV0V1V24UMnuH0RShpnarVhzKoUjw5iX2SflmtS4gwX6/G5r8zhK2Ux71fKgN7XD aVhNtoiUvC66+Z7xK4gjo7ZGbQuMa+Z9DfnycPARQlizJyLjfH4UJyzISijOWCit17d4 sXSztED4ISRCWkpGLpaUI3pVg1CoCn8ZdE4rFO/cCTKOVa0la42nD60MSnM+IXtrKYe6 22etsPcAY/1S+QZ/xAGQPXrKV5GM5cnyyuP0GBg/CXoQ31Yv4NyK+GJHhGm8kDdsRu0m bmIPBPSvWi3iiDiQamDQ69D04G2q8Sn8bhBnZvIDQaE4aoLtUBY/b0LanmuaR/CHGbBc /nqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=FL6m6bT9anjEz6psN8S7zWl6/18GHOiSiimnRAHRM5Y=; b=gyG9fXpHs+tsEyOXyRUIBrxzV0YDdkChafh36LErbzmopr0XAoMwY6sSp/esKzbHwS qn3ArBRSr5ROyvO1l+fVGgiXLPYXZdzW5XSFLwT4HRxozVIJf2wFXAykQRIXWIkO9UkL U/bGL2XxDcfjZ9Y/TVh/2h9Dnt01EEQxAFKD+BcDJzKaz9avwxcHSCB/JZ8aaIJmOsye aCGcqZ78AJ+tiNsVl5afHqxHq4Z8VpdslaYqGBMXXgDXBObiA6s9Zx+w3RX/VNRO+qQY LduPAh8LB78ke7auSE839HS1XDuA3SEnAwoIUL8PqAkJowIQs665yqVdHKCsk2PNjkEa o34w== X-Gm-Message-State: AHYfb5g19bIe7Vsp7ksJWnovikmr2iIWXKj4UWvLW+a8CSi4AKCmxZQK T3E8atMbDI6lz55FoGekcvyOYD4qJtz6 X-Received: by 10.46.64.79 with SMTP id n76mr1605247lja.108.1503523747242; Wed, 23 Aug 2017 14:29:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.21.225 with HTTP; Wed, 23 Aug 2017 14:29:06 -0700 (PDT) From: =?UTF-8?Q?Fernando_Apestegu=C3=ADa?= Date: Wed, 23 Aug 2017 23:29:06 +0200 Message-ID: Subject: Runaway process in -CURRENT To: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2017 21:29:10 -0000 Hi, cad/stepcode is reported as runaway in -CURRENT. It seems to take forever to compile chemas/sdai_wip210e3/SdaiAll.cc. (it uses clang 5.0.0) What strikes me is that it compiles in my machine in about 10 minutes in 11.1 with clang4.0 I attached a debugger to the c++ process that was eating 100% of the CPU time and stopped it from time to time to get a backtrace. It is always in this function: DAGCombiner::MergeConsecutiveStores I finally stopped the compilation since it seemed it wasn't going to finish. Has anyone seen something like this? Thanks in advance. From owner-freebsd-hackers@freebsd.org Thu Aug 24 00:51:50 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AD6F1DF1E69 for ; Thu, 24 Aug 2017 00:51:50 +0000 (UTC) (envelope-from khanzf@gmail.com) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::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 747433349 for ; Thu, 24 Aug 2017 00:51:50 +0000 (UTC) (envelope-from khanzf@gmail.com) Received: by mail-pg0-x236.google.com with SMTP id u191so7935360pgc.2 for ; Wed, 23 Aug 2017 17:51:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=/IanF8N7cN6okQ1Q+zClyPqYrsSnH9bi6+PJbx5iPOo=; b=RB6821wpo40I11h7kVu86bnFPca9EhWxGgDATQuw0oMkrTA/zFWRWTr/XLnx1OZQwZ 3PfAQ1qHkpdImM/yiQlm7i64K2E4MZ+cgardnEpTSDUkekaK4MspvZ5PjX19VKCVSmK8 dmkBbfrFVit+mCtc8X7ZH2epHvLZwfcZqp7Zvs0kxIHF8fso47tsBwL4PjnDyR2OVc0U 0xMfzBLnbRAP6Sko2oOKQDKbHEZVWRD3/+hPScR6OrfGUL0rgmHVgsg0j5j3JDk4n7Hq ZlKIrAHZI4Ir3Z3gfiAJ7YzHpSu73KBkg5KsNywmzMFrHP/EVNhRjOqgaZNEjGfveSjZ ++6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=/IanF8N7cN6okQ1Q+zClyPqYrsSnH9bi6+PJbx5iPOo=; b=fpGIKVmdB88Kbb6GKDiCUlkand5MjAxU9maQ93cfV/cFlFpkpgmpr+TqWX8Fy9l04k R6IT6spK+61Tt5BBoOPqImWuG2lgTF3gUnFf1qEQx4ns9fJNa+NdB9dETO+PLEgbXuDv 07w/tcZA0BsGzTkqzbgzaMwX4L2mdg97dAgo7rDKS31oloDU7gwuyc9XXhZltoWKiygn SehtQ6Q0+HDrDH8A7CjQBVtv/+Jmu6KS31zKoLhWmDMweQVLkGmnHKbrB0wTNVnrWIlb neL4q50TNH4AJbBwE8sna/d73ZIdJtI09BQhxhyw5vEDxeWscLkBa2RXkDqt2Mu89d1Q B+JA== X-Gm-Message-State: AHYfb5geaN3b9Fo/jqNmkJlQhOoK5Zhhq1UTQinm+xeltKwl4Tv0buJS +pgndacuYMnzy9qmRTtnwhborWTACJ6C X-Received: by 10.98.149.205 with SMTP id c74mr257447pfk.194.1503535909753; Wed, 23 Aug 2017 17:51:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.186.237 with HTTP; Wed, 23 Aug 2017 17:51:26 -0700 (PDT) From: Farhan Khan Date: Wed, 23 Aug 2017 20:51:26 -0400 Message-ID: Subject: taskqueue(9) guidance To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 00:51:50 -0000 Hi all, I am trying to understand taskqueue(9) through writing some code, but am unable to get a functioning example. The expected code I thought does not run. I reviewed some sample code within the kernel, mostly drivers. The general pattern I identified was taskqueue_create(9), taskqueue_start_threads(9), and finally the TASK_INIT macro. I also created some structures and place them within the "struct taskqueue" and "struct task". I am not certain why this done, rather than allocate those who structures on their own, but it appeared to be the standard. My code is below: https://pastebin.com/dFqPsA5A I am expecting to see the repeater_proc() function to execute, but that does not occur. Also, I did not specify the frequency, whether it should repeat, etc. I do not understand why the code is not running or what mistake I am making. Please assist. Thank you! -- Farhan Khan PGP Fingerprint: 782F 342B 5B08 0D2F F4E8 82C3 FFA1 CAE1 6536 51CA From owner-freebsd-hackers@freebsd.org Thu Aug 24 05:34:27 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6E8E0DD677B for ; Thu, 24 Aug 2017 05:34:27 +0000 (UTC) (envelope-from matt.joras@gmail.com) Received: from mail-qk0-f195.google.com (mail-qk0-f195.google.com [209.85.220.195]) (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 3596C6B293 for ; Thu, 24 Aug 2017 05:34:26 +0000 (UTC) (envelope-from matt.joras@gmail.com) Received: by mail-qk0-f195.google.com with SMTP id p2so1421468qkf.3 for ; Wed, 23 Aug 2017 22:34:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=XLgvLQg2l/gFnJKm5H4uZffGgKgzZB7XZYrM3pBQZOI=; b=nRODspZ10jwBIawLw8BwoqpPXnHFAq2X9ywftMfywqQbnA58dueSJ+4PDDuftFhAA6 UzHgcGcdyKn9Ir8kN9Hc/CJmDk5bSQJHRMYdNjcH0Jd1BpxaKqvX/I0cNTIseeDYgIRC G/lMbvsZm6LxwyAQ8qos2QaX5sxI5Yk9mv5hB9PHutARXNaVcIPICCKqntgoHAIYWvYz GWxp43H8hpnH56RGogGKjP5q6hmhOBMCn4Fz6QdOQx4XjjmLvEiUaPnvbFqX0akhQv4H xevM4WC/1zMM0y5dpu0UbPKjhP2WHMSFBkvAW6JL7E16Tr22eRhGG7TgKb16+4xoo5tX yZLA== X-Gm-Message-State: AHYfb5gpIvWQuRijOWWs81Zqb3moOFv7N9bTtMiHdcC9nLA47galoqt+ XTIKiPWctvjJtX6XObo= X-Received: by 10.55.165.69 with SMTP id o66mr6445060qke.347.1503549645437; Wed, 23 Aug 2017 21:40:45 -0700 (PDT) Received: from [192.168.2.122] (71-212-20-168.tukw.qwest.net. [71.212.20.168]) by smtp.gmail.com with ESMTPSA id 26sm2067558qtp.60.2017.08.23.21.40.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Aug 2017 21:40:44 -0700 (PDT) Subject: Re: taskqueue(9) guidance To: Farhan Khan , freebsd-hackers@freebsd.org References: From: Matt Joras Message-ID: <34dfe18b-a3ca-515e-5270-43391b5769c0@FreeBSD.org> Date: Wed, 23 Aug 2017 21:40:42 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 05:34:27 -0000 On 08/23/2017 17:51, Farhan Khan wrote: > Hi all, > > I am trying to understand taskqueue(9) through writing some code, but am > unable to get a functioning example. The expected code I thought does not > run. > > I reviewed some sample code within the kernel, mostly drivers. The general > pattern I identified was taskqueue_create(9), taskqueue_start_threads(9), > and finally the TASK_INIT macro. This is more or less the correct steps to initialize a taskqueue and a task. Note however that you often don't need to create your own taskqueue. There are system-wide taskqueues that are available for use, see taskqueue(9). The least specialized one is called taskqueue_thread, and I would suggest you use it instead of making your own taskqueue. Additionally I will note that your taskqueue was declared inside the initialization function, and thus will go out of scope after it returns. This is not what you want. > I also created some structures and place them within the "struct taskqueue" > and "struct task". I am not certain why this done, rather than allocate > those who structures on their own, but it appeared to be the standard. This is a common C pattern that mimics the notion of object inheritance in other languages. The basic idea being that you can make a "specialized" version of a task or taskqueue (e.g. struct my_driver_task) and still use the taskqueue(9) functions since the structure's first member is a struct task or struct taskqueue. For your use case this does not seem necessary. > My code is below: > > https://pastebin.com/dFqPsA5A > > I am expecting to see the repeater_proc() function to execute, but that > does not occur. Also, I did not specify the frequency, whether it should > repeat, etc. > > I do not understand why the code is not running or what mistake I am making. A couple things. Tasks are only run once they are enqueue'd to a taskqueue. You've initialized your task but that simply fills out the structure, it doesn't associate it with the queue. To do that you need to use either taskqueue_enqueue(9) or taskqueue_enqueue_timeout(9). The latter will enqueue the task after a period of time has passed. The task will then eventually be run exactly once. There is no inherent notion of repeating or frequency for tasks. To achieve repetition you are responsible for repeatedly enqueueing your task to a taskqueue. Hope that helps. Matt Joras From owner-freebsd-hackers@freebsd.org Thu Aug 24 08:58:49 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BA614DD9E46 for ; Thu, 24 Aug 2017 08:58:49 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:470:7a58:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7CC476FED7 for ; Thu, 24 Aug 2017 08:58:49 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2a03:fc02:2:1:b981:7051:fe8a:e399] (unknown [IPv6:2a03:fc02:2:1:b981:7051:fe8a:e399]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 8ADB630C66; Thu, 24 Aug 2017 10:58:45 +0200 (CEST) From: Dimitry Andric Message-Id: <71697463-4E52-4B46-B60B-00BDD87D8A2C@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_E71674AC-2B88-45EA-B53D-0D4E2EE282D2"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Runaway process in -CURRENT Date: Thu, 24 Aug 2017 10:58:44 +0200 In-Reply-To: Cc: FreeBSD Hackers To: =?utf-8?Q?Fernando_Apestegu=C3=ADa?= References: X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 08:58:49 -0000 --Apple-Mail=_E71674AC-2B88-45EA-B53D-0D4E2EE282D2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 23 Aug 2017, at 23:29, Fernando Apestegu=C3=ADa = wrote: >=20 > cad/stepcode is reported as runaway in -CURRENT. Where is this report? > It seems to take > forever to compile chemas/sdai_wip210e3/SdaiAll.cc. (it uses clang > 5.0.0) Not for me, it compiles in slightly more than 2 seconds: clang-4.0.0 2.20 real 2.11 user 0.08 sys clang-5.0.0-r311219 2.16 real 2.00 user 0.15 sys Are you using any special CFLAGS or CPUTYPE settings? > What strikes me is that it compiles in my machine in about 10 minutes > in 11.1 with clang4.0 Are you talking about the build of the entire port, or just that one source file? The whole port takes quite a while to build, but it does finish for me. -Dimitry --Apple-Mail=_E71674AC-2B88-45EA-B53D-0D4E2EE282D2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.1 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCWZ6VRAAKCRCwXqMKLiCW oxVkAKDxVQpPniOPTBrr/uSQHYeqZlLJlQCg7PdVh21ae88ui2XWkKS306RjbX0= =ZYKp -----END PGP SIGNATURE----- --Apple-Mail=_E71674AC-2B88-45EA-B53D-0D4E2EE282D2-- From owner-freebsd-hackers@freebsd.org Thu Aug 24 09:15:01 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7E7F6DDA6B5 for ; Thu, 24 Aug 2017 09:15:01 +0000 (UTC) (envelope-from fernando.apesteguia@gmail.com) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 00C8470B4F; Thu, 24 Aug 2017 09:15:01 +0000 (UTC) (envelope-from fernando.apesteguia@gmail.com) Received: by mail-lf0-x231.google.com with SMTP id r2so194129lff.3; Thu, 24 Aug 2017 02:15:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ccDXt2fqj3CmS+6TFCFK/lUEAahX9lvOi26JLHk3NwM=; b=Okja2TKryhUDG2EHPk8XSPR045fmNfZ8hgvn2BMxjVHU+VGKCjDsJRyiLMp1+QAW0f EKPYco8qMrsgPtVQoF5ZDd6cbEs5IXiSxWgyR3AVvupn3QBSgvbkbMUiMxEV8YO1heco HnOb4eTm7dmD95SO5UTruvhdyGH9/L156r8kpgMQKX3L1tY196ufsRVlUeorZOsZDXgo rB8rmrQUQ+LEO/6uucxV1d98QV1XRmfeWXQueN6p84I12ThdE7wNz26gMbsam4ohm81f QLU+zQN08ReQyHSHjuav1cYyhKV5FY7loYNj+ZrElABJeJS09GVQT2pTBT8bMzDfyymL kNkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ccDXt2fqj3CmS+6TFCFK/lUEAahX9lvOi26JLHk3NwM=; b=eROAThubXN19IPcJtMcLQZCiPuj0lNehcV2RwwTGI0VYKJFvJ4gz4NIbw7blsbtELm Lz63IXi7zCnq1clhnuUUtS5WaSWE4C1BP865CY6FqEVOw6JfUcJAi6N1sOoD4JOg21rZ QFHQlrtLi6C2klzr/sigtmNeW4sSiwY5aa9BCVsprkj9AiTh9zCUEUqDQ0WxQF3EbyyB QZWkV1Cj7/6njEAJo6W1sYKxMrkNDjsMiVw/O8YCO49MpuJ0tfdSUZFEWza/96TODElV fnP1mIt/Siq9i0wn3TytqaEavGsVcuKeE+sX+QGJOJMWx8ikxhgxuYV779vxivUMdv9d DYOw== X-Gm-Message-State: AHYfb5jsHw8d5PxuzokW+Hkb+OvWI4n33ccBNeYZZG8mSaF+zXqUqbgb kMVZNkmgangISr83BXf+9ndYtNWW+g== X-Received: by 10.46.5.67 with SMTP id 64mr1888741ljf.157.1503566098607; Thu, 24 Aug 2017 02:14:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.21.225 with HTTP; Thu, 24 Aug 2017 02:14:57 -0700 (PDT) Received: by 10.25.21.225 with HTTP; Thu, 24 Aug 2017 02:14:57 -0700 (PDT) In-Reply-To: References: <71697463-4E52-4B46-B60B-00BDD87D8A2C@FreeBSD.org> From: =?UTF-8?Q?Fernando_Apestegu=C3=ADa?= Date: Thu, 24 Aug 2017 11:14:57 +0200 Message-ID: Subject: Re: Runaway process in -CURRENT To: Dimitry Andric Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 09:15:01 -0000 El 24 ago. 2017 10:58, "Dimitry Andric" escribi=C3=B3: On 23 Aug 2017, at 23:29, Fernando Apestegu=C3=ADa wrote: > > cad/stepcode is reported as runaway in -CURRENT. Where is this report? In the mail that was sent to me it says it's here: http://beefy11.nyi.freebsd.org/data/head-i386-default/p448504_s322776/logs/= stepcode-0.8_1.log But I can't access that url > It seems to take > forever to compile chemas/sdai_wip210e3/SdaiAll.cc. (it uses clang > 5.0.0) Not for me, it compiles in slightly more than 2 seconds: clang-4.0.0 2.20 real 2.11 user 0.08 sys clang-5.0.0-r311219 2.16 real 2.00 user 0.15 sys Are you using any special CFLAGS or CPUTYPE settings? Sorry, I should have started this clearly: I'm receiving this reports from the project ports builders, but I can reproduce it in my machine with -CURRENT in VirtualBox. No special flags on my setup though > What strikes me is that it compiles in my machine in about 10 minutes > in 11.1 with clang4.0 Are you talking about the build of the entire port, or just that one source file? The whole port takes quite a while to build, but it does finish for me. The entire port. -Dimitry From owner-freebsd-hackers@freebsd.org Thu Aug 24 14:42:17 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0E79DDE1162 for ; Thu, 24 Aug 2017 14:42:17 +0000 (UTC) (envelope-from fernando.apesteguia@gmail.com) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::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 A1D927F4F0; Thu, 24 Aug 2017 14:42:16 +0000 (UTC) (envelope-from fernando.apesteguia@gmail.com) Received: by mail-lf0-x229.google.com with SMTP id i188so3818385lfg.2; Thu, 24 Aug 2017 07:42:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=/5SLdXA/ZIycWhuCeoZ/rmjz3TL2AX9NOI+VLmD8nvM=; b=bQsSQdl3M//YbaObydwNqN4/RrjBozvUOOBgZJJ4NWRpD7jSCuPQuwWVIGCPwlvkUb awPPjn+um4e+t/VAL/mcFeY/zXNikxIsyT/oTnMcZ5BM308dk44fpcHwntDYygiqpkM2 FhVi/B7L0R1W6LPNKxajcCc8dMsawGhin3nc7IW+51+lxPgh2fXUcULq6JSQTbgRf5Vq k+0bg61F+SoXFu2snkvW/dCMV2mYOFBXPKg+/jo7f3/10Cy+uJu2pYPlA005MQgSWfAs wusKHJW7wDZsgy4sWoRR3VhgjN5LHPVU2AlkTlxZqfuacgX1hu5AxWJ2TsohZEx2R25z lMxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=/5SLdXA/ZIycWhuCeoZ/rmjz3TL2AX9NOI+VLmD8nvM=; b=hXFSrkgc/IzjOTOkNGbgyJ7vG/UF47OLTvR+R217ZE1SrHC7fYm044NyF9S9mzQUyc 03KCWb4WinecaqWZ0hpj0Euc+7qYX1rk6Rp1OJ/HqMOf7K++ZnqnGsDSN7PfM6SP6meZ KBzihl+OF4hc0Ymv1f0fG/Ke/sNgQojW3m5GE0un27J4HhJAX6ao56Na7+zrtaD/dj5z DkQi2N2joyRSHw+VTpLY13sawyPzVwbm6J7fMc+ruwAm/RC6E4W7Dz1+9h8nHjHn0CB7 BVtSnlwaTPtqS083KHV/UqUzN8Fru752R6oVZ0WweVdorufO4Tkt9uKuTTwUTAGuEokW AOlQ== X-Gm-Message-State: AHYfb5i2pRwvs28QcYPIHSrMmWPijflLrd7h7j0IT9zIn163NtynUzEk Nb1xbWhGnfci/s+TQSgE0WmZpzE7TW/s X-Received: by 10.46.9.65 with SMTP id 62mr2601245ljj.177.1503585733314; Thu, 24 Aug 2017 07:42:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.21.225 with HTTP; Thu, 24 Aug 2017 07:42:12 -0700 (PDT) In-Reply-To: References: <71697463-4E52-4B46-B60B-00BDD87D8A2C@FreeBSD.org> From: =?UTF-8?Q?Fernando_Apestegu=C3=ADa?= Date: Thu, 24 Aug 2017 16:42:12 +0200 Message-ID: Subject: Re: Runaway process in -CURRENT To: Dimitry Andric Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 14:42:17 -0000 On Thu, Aug 24, 2017 at 11:14 AM, Fernando Apestegu=C3=ADa wrote: > > > El 24 ago. 2017 10:58, "Dimitry Andric" escribi=C3=B3: > > On 23 Aug 2017, at 23:29, Fernando Apestegu=C3=ADa > wrote: >> >> cad/stepcode is reported as runaway in -CURRENT. > > Where is this report? > > > In the mail that was sent to me it says it's here: > > http://beefy11.nyi.freebsd.org/data/head-i386-default/p448504_s322776/log= s/stepcode-0.8_1.log > > But I can't access that url > Just for the record, I got another email. Log URL: http://beefy11.nyi.freebsd.org/data/head-i386-default/p448640_s322824/logs/= stepcode-0.8_1.log Last lines of the report are these: /stepcode-0.8/src/cldai -I/wrkdirs/usr/ports/cad/stepcode/work/stepcode-0.8/src/cleditor -I/wrkdirs/usr/ports/cad/stepcode/work/stepcode-0.8/src/clutils -I/wrkdirs/usr/ports/cad/stepcode/work/stepcode-0.8/src/clstepcore -I/wrkdirs/usr/ports/cad/stepcode/work/stepcode-0.8/src/base -I/wrkdirs/usr/ports/cad/stepcode/work/stepcode-0.8/src/base/judy/src -O2 -pipe -fstack-protector -fno-strict-aliasing -O2 -pipe -fstack-protector -fno-strict-aliasing -fPIC -pedantic -W -Wall -Wundef -Wfloat-equal -Wshadow -Winline -Wno-long-long -MD -MT schemas/sdai_wip210e3/CMakeFiles/sdai_wip210e3.dir/SdaiAP210_ELECTRONIC_ASS= EMBLY_INTERCONNECT_AND_PACKAGING_DESIGN_MIM_LF_unity_types.cc.o -MF schemas/sdai_wip210e3/CMakeFiles/sdai_wip210e3.dir/SdaiAP210_ELECTRONIC= _ASSEMBLY_INTERCONNECT_AND_PACKAGING_DESIGN _MIM_LF_unity_types.cc.o.d -o schemas/sdai_wip210e3/CMakeFiles/sdai_wip210e3.dir/SdaiAP210_ELECTRONIC_ASS= EMBLY_INTERCONNECT_AND_PACKAGING_DESIGN_MIM_LF_unity_types.cc.o -c schemas/sdai_wip210e3/SdaiAP210_ELECTRONIC_ASSEMBLY_INTERCONNECT_AND_PAC= KAGING_DESIGN_MIM_LF_unity_types.cc [411/421] /usr/bin/c++ -DSC_SDAI_UNITY_BUILD -Dsdai_wip210e3_EXPORTS -I/wrkdirs/usr/ports/cad/stepcode/work/stepcode-0.8/include -Iinclude -Ischemas/sdai_wip210e3 -I/wrkdirs/usr/ports/cad/stepcode/work/stepcode-0.8/src/cldai -I/wrkdirs/usr/ports/cad/stepcode/work/stepcode-0.8/src/cleditor -I/wrkdirs/usr/ports/cad/stepcode/work/stepcode-0.8/src/clutils -I/wrkdirs/usr/ports/cad/stepcode/work/stepcode-0.8/src/clstepcore -I/wrkdirs/usr/ports/cad/stepcode/work/stepcode-0.8/src/base -I/wrkdirs/usr/ports/cad/stepcode/work/stepcode-0.8/src/base/judy/src -O2 -pipe -fstack-protector -fno-strict-aliasing -O2 -pipe -fstack-protector -fno-strict-aliasing -fPIC -pedantic -W -Wall -Wundef -Wfloat-equal -Wshadow -Winline -Wno-long-long -MD -MT schemas/sdai_wip210e3/CMakeFiles/sdai_wip210e3.dir/SdaiAll.cc.o -MF schemas/sdai_wip210e3/CMakeFiles/sdai_wip210e3.dir/SdaiAll.cc.o.d -o schemas/sdai_wip210e3/CMakeFiles/sdai_wip210e3.dir/SdaiAll.cc.o -c schemas/sdai_wip210e3/SdaiAll.cc =3D=3D=3D=3D>> Killing runaway build after 7200 seconds with no output > > >> It seems to take >> forever to compile chemas/sdai_wip210e3/SdaiAll.cc. (it uses clang >> 5.0.0) > > Not for me, it compiles in slightly more than 2 seconds: > > clang-4.0.0 2.20 real 2.11 user 0.08 sys > clang-5.0.0-r311219 2.16 real 2.00 user 0.15 sys > > Are you using any special CFLAGS or CPUTYPE settings? > > > Sorry, I should have started this clearly: I'm receiving this reports fro= m > the project ports builders, but I can reproduce it in my machine with > -CURRENT in VirtualBox. > > No special flags on my setup though > > > >> What strikes me is that it compiles in my machine in about 10 minutes >> in 11.1 with clang4.0 > > Are you talking about the build of the entire port, or just that one > source file? The whole port takes quite a while to build, but it does > finish for me. > > > The entire port. > > > -Dimitry > > From owner-freebsd-hackers@freebsd.org Thu Aug 24 18:15:48 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A980ADE54A9 for ; Thu, 24 Aug 2017 18:15:48 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 696301944; Thu, 24 Aug 2017 18:15:48 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:470:7a58::3582:7cb6:200b:aa6d] (unknown [IPv6:2001:470:7a58:0:3582:7cb6:200b:aa6d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 6749730CA3; Thu, 24 Aug 2017 20:15:40 +0200 (CEST) From: Dimitry Andric Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_CA0A6D5A-0480-4BCC-8553-52B4A5ED8945"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Runaway process in -CURRENT Date: Thu, 24 Aug 2017 20:15:34 +0200 In-Reply-To: Cc: FreeBSD Hackers , Ed Maste , Benjamin Kramer , Hans Wennborg To: =?utf-8?Q?Fernando_Apestegu=C3=ADa?= References: <71697463-4E52-4B46-B60B-00BDD87D8A2C@FreeBSD.org> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 18:15:48 -0000 --Apple-Mail=_CA0A6D5A-0480-4BCC-8553-52B4A5ED8945 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 24 Aug 2017, at 16:42, Fernando Apestegu=C3=ADa = wrote: >=20 > On Thu, Aug 24, 2017 at 11:14 AM, Fernando Apestegu=C3=ADa > wrote: ... > Just for the record, I got another email. Log URL: >=20 > = http://beefy11.nyi.freebsd.org/data/head-i386-default/p448640_s322824/logs= /stepcode-0.8_1.log ... > schemas/sdai_wip210e3/CMakeFiles/sdai_wip210e3.dir/SdaiAll.cc.o -MF > schemas/sdai_wip210e3/CMakeFiles/sdai_wip210e3.dir/SdaiAll.cc.o.d -o > schemas/sdai_wip210e3/CMakeFiles/sdai_wip210e3.dir/SdaiAll.cc.o -c > schemas/sdai_wip210e3/SdaiAll.cc > =3D=3D=3D=3D>> Killing runaway build after 7200 seconds with no output Hm, I had not noticed two facts, one being that there are a great many copies of SdaiAll.cc files, which all seem to be generated, and the other that this is occurring on i386. There are also other generated files, and specifically the compstructs.cc files can take extremely long to compile. On amd64, the longest compile time in the whole port is ~185 seconds, for a generated file of ~28000 lines: time lines filename =3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 184.90 28345 schemas/sdai_wip210e3/compstructs.cc 115.08 103 = schemas/sdai_ap239/SdaiAP239_PRODUCT_LIFE_CYCLE_SUPPORT_ARM_LF_unity_types= .cc 110.00 440 = schemas/sdai_cd209/SdaiAP209_MULTIDISCIPLINARY_ANALYSIS_AND_DESIGN_MIM_LF_= unity_types.cc 106.70 292 = schemas/sdai_wip210e3/SdaiAP210_ELECTRONIC_ASSEMBLY_INTERCONNECT_AND_PACKA= GING_DESIGN_MIM_LF_unity_types.cc 90.73 290 = schemas/sdai_cd242/SdaiAP242_MANAGED_MODEL_BASED_3D_ENGINEERING_MIM_LF_uni= ty_types.cc 88.77 2232 = schemas/sdai_cd209/SdaiAP209_MULTIDISCIPLINARY_ANALYSIS_AND_DESIGN_MIM_LF_= unity_entities.cc 81.87 2174 = schemas/sdai_wip210e3/SdaiAP210_ELECTRONIC_ASSEMBLY_INTERCONNECT_AND_PACKA= GING_DESIGN_MIM_LF_unity_entities.cc 73.92 19658 schemas/sdai_cd209/compstructs.cc 64.82 1734 = schemas/sdai_cd242/SdaiAP242_MANAGED_MODEL_BASED_3D_ENGINEERING_MIM_LF_uni= ty_entities.cc 61.42 189 = schemas/sdai_ap210e2/SdaiAP210_ELECTRONIC_ASSEMBLY_INTERCONNECT_AND_PACKAG= ING_DESIGN_MIM_LF_unity_types.cc On i386, this time is enormously increased, especially for the files with lots of lines: time lines filename =3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 4809.23 28345 schemas/sdai_wip210e3/compstructs.cc 2164.37 19658 schemas/sdai_cd209/compstructs.cc 2056.54 15806 schemas/sdai_ap210e2/compstructs.cc 1545.19 16679 schemas/sdai_cd242/compstructs.cc 446.49 7667 schemas/sdai_ap203e2/compstructs.cc 273.96 6297 schemas/sdai_ap214e3/compstructs.cc 187.16 103 = schemas/sdai_ap239/SdaiAP239_PRODUCT_LIFE_CYCLE_SUPPORT_ARM_LF_unity_types= .cc 163.39 440 = schemas/sdai_cd209/SdaiAP209_MULTIDISCIPLINARY_ANALYSIS_AND_DESIGN_MIM_LF_= unity_types.cc 130.02 2232 = schemas/sdai_cd209/SdaiAP209_MULTIDISCIPLINARY_ANALYSIS_AND_DESIGN_MIM_LF_= unity_entities.cc 122.15 290 = schemas/sdai_cd242/SdaiAP242_MANAGED_MODEL_BASED_3D_ENGINEERING_MIM_LF_uni= ty_types.cc The compstructs.cc and SdaiAll.cc files contain *extremely* large generated functions, in most cases embodying the whole file, even. It seems that this is the cause for the long compile times. A test case tarball with the preprocessed version of the top compstructs.cc file, and a shell script to run it, is here: http://www.andric.com/freebsd/clang/stepcode.tar.xz With clang 4.0.0, the compile times are more at the level of the amd64 builds, even on i386. So this regressed somewhere along the way to 5.0.0. I will have to try to find out where, to see if there is an existing bug report or workaround. Note that in r321664, about three weeks ago, I already committed a couple of upstream fixes for some situations where compile times could get excessive (see also https://bugs.llvm.org/show_bug.cgi?id=3D33900), but it doesn't seem to have helped in this case. As a quick workaround, the port can be modified to compile these files using a lower optimization level. If -O1 is used for the longest case, e.g. schemas/sdai_wip210e3/compstructs.cc, the compile time drops down to ~30s. I don't think it will matter very much for the speed or size of the output. -Dimitry --Apple-Mail=_CA0A6D5A-0480-4BCC-8553-52B4A5ED8945 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.1 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCWZ8XxgAKCRCwXqMKLiCW o5poAJ0cJ1pF6j7vSKpYl9y3dsyrKg6qEgCgtwYrJQRKKuZlsahlStSK121oOFs= =wlbL -----END PGP SIGNATURE----- --Apple-Mail=_CA0A6D5A-0480-4BCC-8553-52B4A5ED8945-- From owner-freebsd-hackers@freebsd.org Thu Aug 24 18:27:50 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 45D0DDE5962 for ; Thu, 24 Aug 2017 18:27:50 +0000 (UTC) (envelope-from fernando.apesteguia@gmail.com) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010: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 BC5692197; Thu, 24 Aug 2017 18:27:49 +0000 (UTC) (envelope-from fernando.apesteguia@gmail.com) Received: by mail-lf0-x22c.google.com with SMTP id z130so1107868lff.3; Thu, 24 Aug 2017 11:27:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=6/1DaqOxPXq0jaIkJzMADmYvuJgVQTZbLyOswHA5i1Y=; b=qhpxoUQUKeQf6KBMMqtfCIcJBDS0qJ/CCQa2/HwLWrewymc9bOYc+ErGnaQezRfuzJ RyBOjaFDcgnXkErTWFlTgpT9Qhh6MxIvVZiGipv719pGmf1I6dg6XhjiFCVp5B9FDgAh uJvQQ4VTydcXvkYBshzYDDufYvNx8kf66YbiHlsc0RLnx78PXriLGv7dOP4bROFnODTA oSrPeVN6MLGGkELBIR6B3EPyT81zCWt6fFxzv6L0xa7qEVYRCJ4PU8nMYpJVRDPANheX xQt/5Bl1V5Ac9IPBHn7Jyk8iQU74DYDytWRZrgOL5UFZ0jqWBbguEO+f1EfZOOZs3lrd MkiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=6/1DaqOxPXq0jaIkJzMADmYvuJgVQTZbLyOswHA5i1Y=; b=HG6t0WOZgYDojsSEfA6cpiJLBFZCR/sbCEltugIWCKZQmVKAL41+h5PUgQh8rMDVSP aZbTemm5oMJcQLOE5AfNudo1rcfN1Fs5e3MPk6dWqtqDTlCkG+bj74lTkHG5aIQjA02U Zaf/rJT5XYYsmaZKiFixOy6NadRzWYD5LDnzR0iy6LKpGVe7Ql8QSIBXkUfYEEwC3gH5 y6grLXChOTSmrIwzCcOdDPMRInWZUZsXG08ZzboQjOVY5PtxIZk3Dn0OYKcKmlSZWXjC x7rR890nQdtGfMhWvEu0r46cl5eGmJMqNK22PlEAw3CxGDn31fY0nvp3v6KL6NWLa0ai 37XQ== X-Gm-Message-State: AHYfb5hAw1IHRjz++9ZtwqzK2IYCNmNw+3Hlp2+xJHS2wo33qxTQxdzi 07VxNZ+LYPyJ0US6DuNQbGMERmerehXO X-Received: by 10.46.9.65 with SMTP id 62mr2846326ljj.177.1503599267557; Thu, 24 Aug 2017 11:27:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.21.225 with HTTP; Thu, 24 Aug 2017 11:27:46 -0700 (PDT) In-Reply-To: References: <71697463-4E52-4B46-B60B-00BDD87D8A2C@FreeBSD.org> From: =?UTF-8?Q?Fernando_Apestegu=C3=ADa?= Date: Thu, 24 Aug 2017 20:27:46 +0200 Message-ID: Subject: Re: Runaway process in -CURRENT To: Dimitry Andric Cc: FreeBSD Hackers , Ed Maste , Benjamin Kramer , Hans Wennborg Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 18:27:50 -0000 On Thu, Aug 24, 2017 at 8:15 PM, Dimitry Andric wrote: > On 24 Aug 2017, at 16:42, Fernando Apestegu=C3=ADa wrote: >> >> On Thu, Aug 24, 2017 at 11:14 AM, Fernando Apestegu=C3=ADa >> wrote: > ... >> Just for the record, I got another email. Log URL: >> >> http://beefy11.nyi.freebsd.org/data/head-i386-default/p448640_s322824/lo= gs/stepcode-0.8_1.log > ... >> schemas/sdai_wip210e3/CMakeFiles/sdai_wip210e3.dir/SdaiAll.cc.o -MF >> schemas/sdai_wip210e3/CMakeFiles/sdai_wip210e3.dir/SdaiAll.cc.o.d -o >> schemas/sdai_wip210e3/CMakeFiles/sdai_wip210e3.dir/SdaiAll.cc.o -c >> schemas/sdai_wip210e3/SdaiAll.cc >> =3D=3D=3D=3D>> Killing runaway build after 7200 seconds with no output > > Hm, I had not noticed two facts, one being that there are a great many > copies of SdaiAll.cc files, which all seem to be generated, and the > other that this is occurring on i386. There are also other generated > files, and specifically the compstructs.cc files can take extremely long > to compile. > > On amd64, the longest compile time in the whole port is ~185 seconds, > for a generated file of ~28000 lines: > > time lines filename > =3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > 184.90 28345 schemas/sdai_wip210e3/compstructs.cc > 115.08 103 schemas/sdai_ap239/SdaiAP239_PRODUCT_LIFE_CYCLE_SUPPORT_A= RM_LF_unity_types.cc > 110.00 440 schemas/sdai_cd209/SdaiAP209_MULTIDISCIPLINARY_ANALYSIS_A= ND_DESIGN_MIM_LF_unity_types.cc > 106.70 292 schemas/sdai_wip210e3/SdaiAP210_ELECTRONIC_ASSEMBLY_INTER= CONNECT_AND_PACKAGING_DESIGN_MIM_LF_unity_types.cc > 90.73 290 schemas/sdai_cd242/SdaiAP242_MANAGED_MODEL_BASED_3D_ENGIN= EERING_MIM_LF_unity_types.cc > 88.77 2232 schemas/sdai_cd209/SdaiAP209_MULTIDISCIPLINARY_ANALYSIS_A= ND_DESIGN_MIM_LF_unity_entities.cc > 81.87 2174 schemas/sdai_wip210e3/SdaiAP210_ELECTRONIC_ASSEMBLY_INTER= CONNECT_AND_PACKAGING_DESIGN_MIM_LF_unity_entities.cc > 73.92 19658 schemas/sdai_cd209/compstructs.cc > 64.82 1734 schemas/sdai_cd242/SdaiAP242_MANAGED_MODEL_BASED_3D_ENGIN= EERING_MIM_LF_unity_entities.cc > 61.42 189 schemas/sdai_ap210e2/SdaiAP210_ELECTRONIC_ASSEMBLY_INTERC= ONNECT_AND_PACKAGING_DESIGN_MIM_LF_unity_types.cc > > On i386, this time is enormously increased, especially for the files > with lots of lines: > > time lines filename > =3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > 4809.23 28345 schemas/sdai_wip210e3/compstructs.cc > 2164.37 19658 schemas/sdai_cd209/compstructs.cc > 2056.54 15806 schemas/sdai_ap210e2/compstructs.cc > 1545.19 16679 schemas/sdai_cd242/compstructs.cc > 446.49 7667 schemas/sdai_ap203e2/compstructs.cc > 273.96 6297 schemas/sdai_ap214e3/compstructs.cc > 187.16 103 schemas/sdai_ap239/SdaiAP239_PRODUCT_LIFE_CYCLE_SUPPORT_A= RM_LF_unity_types.cc > 163.39 440 schemas/sdai_cd209/SdaiAP209_MULTIDISCIPLINARY_ANALYSIS_A= ND_DESIGN_MIM_LF_unity_types.cc > 130.02 2232 schemas/sdai_cd209/SdaiAP209_MULTIDISCIPLINARY_ANALYSIS_A= ND_DESIGN_MIM_LF_unity_entities.cc > 122.15 290 schemas/sdai_cd242/SdaiAP242_MANAGED_MODEL_BASED_3D_ENGIN= EERING_MIM_LF_unity_types.cc > I did some tests: -CURRENT (i326) in VirtualBox, 1 CPU, 8Gb RAM cd /usr/ports/cad/stepcode && time make * gcc 6.4.0 real 27m17.867s user 50m.0.428s sys 2m47.619 * clang38 real 18m28.996s user 33m22.790s sys 1m22.711s * clang 5.0.0 It takes a lot of time compiling schemas/sdai_{wip210e3,ap210e2}/SdaiAll.cc and other SdaAll.cc files. It's still compiling after several hours. > The compstructs.cc and SdaiAll.cc files contain *extremely* large > generated functions, in most cases embodying the whole file, even. It > seems that this is the cause for the long compile times. A test case > tarball with the preprocessed version of the top compstructs.cc file, > and a shell script to run it, is here: > http://www.andric.com/freebsd/clang/stepcode.tar.xz > > With clang 4.0.0, the compile times are more at the level of the amd64 > builds, even on i386. So this regressed somewhere along the way to > 5.0.0. I will have to try to find out where, to see if there is an > existing bug report or workaround. > > Note that in r321664, about three weeks ago, I already committed a > couple of upstream fixes for some situations where compile times could > get excessive (see also https://bugs.llvm.org/show_bug.cgi?id=3D33900), > but it doesn't seem to have helped in this case. > > As a quick workaround, the port can be modified to compile these files > using a lower optimization level. If -O1 is used for the longest case, > e.g. schemas/sdai_wip210e3/compstructs.cc, the compile time drops down > to ~30s. I don't think it will matter very much for the speed or size > of the output. I'll have a look at this. Thanks! > > -Dimitry > From owner-freebsd-hackers@freebsd.org Fri Aug 25 04:32:42 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F158ADEF55C for ; Fri, 25 Aug 2017 04:32:42 +0000 (UTC) (envelope-from khanzf@gmail.com) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::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 C2A627283C; Fri, 25 Aug 2017 04:32:42 +0000 (UTC) (envelope-from khanzf@gmail.com) Received: by mail-pg0-x22c.google.com with SMTP id b8so8496205pgn.5; Thu, 24 Aug 2017 21:32:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SWDSmc2vO+nX6n8K0HDFi5JRF3ei/955B0IOPA/KU/I=; b=Ld1BM+fdWnOpOd/dQf++JyLw1bi1zT3KJ8NQAuaYEmzQPoELcInqScsGnVfUJkAItv L8zZ/CxhlpGOAbfW2J0XRwGr9bbjoEAL3e6DJjrJFRSrm+hAATkeFHWMSbsrkMZRPDnc LW7B806oXCnU6OKxvVvL1/9MsbQeQIPdlXkfgmnxjIMhM6bC+SG8FDhnH/ji0MsYS5I0 SkmVK3GJ0RuooKRfvK+hMnK/cHiRLqPO3t+BMatp+9P2nN0r++vnhMKOXuvfGKEAhwsW OWn6Iy/jzc+M+vl+lsOlmFMd57L3qezwCjImeY+xae5cCaFYiuskn6fppn50hL8qSNdI vReg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SWDSmc2vO+nX6n8K0HDFi5JRF3ei/955B0IOPA/KU/I=; b=lbZIiEXxnv2a8FS4xUAyBQM1OIdA4K9EqL8Ugyf3wKJ+rogsRqEa1z5RzjyknGiQK/ VZbPVYIYVgZjT551pieBaUV+2NXwneEgwHKl3Kg9AjgdmGmOUC7kMQJJg+1xDeE3P+9P 0+Vil8oVVYzem88u6BYfxOdNujSGYUthFf8q2K0GlnWdZhLLTk3P3Zbz9bikqVHgWrP6 TYMuiiwEaOU3P8deoEHI0EgQdMRAonyb6zsdkgS42dTFN7C2Qqc5YxkM/98HIuojcm68 8gILkULn5oOAZm3G5qoryX4NL4nuY8UdVlAn+jeLKaAyAibGDHqRo3ConxcZCyxFKlou J9Gg== X-Gm-Message-State: AHYfb5hFkNoxlzB/nGcpZH5RgQ/uksDiHtSV5Sg0K6Sx9H8eioSc6ho9 SuaNR+vZvxYAd3mGALA5J/wPh7bKAlJLq+M= X-Received: by 10.84.232.204 with SMTP id x12mr9510018plm.364.1503635562098; Thu, 24 Aug 2017 21:32:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.183.208 with HTTP; Thu, 24 Aug 2017 21:32:21 -0700 (PDT) In-Reply-To: <34dfe18b-a3ca-515e-5270-43391b5769c0@FreeBSD.org> References: <34dfe18b-a3ca-515e-5270-43391b5769c0@FreeBSD.org> From: Farhan Khan Date: Fri, 25 Aug 2017 00:32:21 -0400 Message-ID: Subject: Re: taskqueue(9) guidance To: Matt Joras Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 04:32:43 -0000 Thank you for your explanation! As you mentioned, I just needed to use taskqueue_enqueue(9). I did not use the system-wide taskqueue, but I saw it in the manual. I personally did not find any examples on Google and found the man pages a bit too abstract, so I cleaned up my code example and put it online for the next person. Hope it helps! https://gist.github.com/khanzf/465eec49d5008f460aa0571604267d7b -- Farhan Khan PGP Fingerprint: 782F 342B 5B08 0D2F F4E8 82C3 FFA1 CAE1 6536 51CA On Thu, Aug 24, 2017 at 12:40 AM, Matt Joras wrote: > On 08/23/2017 17:51, Farhan Khan wrote: > > Hi all, > > > > I am trying to understand taskqueue(9) through writing some code, but am > > unable to get a functioning example. The expected code I thought does not > > run. > > > > I reviewed some sample code within the kernel, mostly drivers. The > general > > pattern I identified was taskqueue_create(9), taskqueue_start_threads(9), > > and finally the TASK_INIT macro. > This is more or less the correct steps to initialize a taskqueue and a > task. Note however that you often don't need to create your own > taskqueue. There are system-wide taskqueues that are available for use, > see taskqueue(9). The least specialized one is called taskqueue_thread, > and I would suggest you use it instead of making your own taskqueue. > Additionally I will note that your taskqueue was declared inside the > initialization function, and thus will go out of scope after it returns. > This is not what you want. > > I also created some structures and place them within the "struct > taskqueue" > > and "struct task". I am not certain why this done, rather than allocate > > those who structures on their own, but it appeared to be the standard. > This is a common C pattern that mimics the notion of object inheritance > in other languages. The basic idea being that you can make a > "specialized" version of a task or taskqueue (e.g. struct > my_driver_task) and still use the taskqueue(9) functions since the > structure's first member is a struct task or struct taskqueue. For your > use case this does not seem necessary. > > My code is below: > > > > https://pastebin.com/dFqPsA5A > > > > I am expecting to see the repeater_proc() function to execute, but that > > does not occur. Also, I did not specify the frequency, whether it should > > repeat, etc. > > > > I do not understand why the code is not running or what mistake I am > making. > > A couple things. Tasks are only run once they are enqueue'd to a > taskqueue. You've initialized your task but that simply fills out the > structure, it doesn't associate it with the queue. To do that you need > to use either taskqueue_enqueue(9) or taskqueue_enqueue_timeout(9). The > latter will enqueue the task after a period of time has passed. The task > will then eventually be run exactly once. There is no inherent notion of > repeating or frequency for tasks. To achieve repetition you are > responsible for repeatedly enqueueing your task to a taskqueue. > > Hope that helps. > > Matt Joras > > From owner-freebsd-hackers@freebsd.org Fri Aug 25 06:32:17 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 12B00DF0B12 for ; Fri, 25 Aug 2017 06:32:17 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-57.reflexion.net [208.70.210.57]) (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 A9F3F74F78 for ; Fri, 25 Aug 2017 06:32:16 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 7559 invoked from network); 25 Aug 2017 06:37:18 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 25 Aug 2017 06:37:18 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.2) with SMTP; Fri, 25 Aug 2017 02:32:09 -0400 (EDT) Received: (qmail 31944 invoked from network); 25 Aug 2017 06:32:09 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 25 Aug 2017 06:32:09 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 9CF8FEC9255; Thu, 24 Aug 2017 23:32:08 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: svn commit: r322875 - head/sys/dev/nvme Message-Id: <1C5A448F-C91A-4599-8500-E4E46E6F5205@dsl-only.net> Date: Thu, 24 Aug 2017 23:32:07 -0700 To: imp@FreeBSD.org, svn-src-head@freebsd.org, FreeBSD Current , FreeBSD-STABLE Mailing List , freebsd-hackers X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 06:32:17 -0000 > Author: imp > Date: Fri Aug 25 04:33:06 2017 > New Revision: 322875 > URL:=20 > https://svnweb.freebsd.org/changeset/base/322875 >=20 >=20 > Log: > Use _Static_assert > =20 > These files are compiled in userland too, so we can't use = sys/systm.h > and rely on CTASSERT. Switch to using _Static_assert instead. > =20 > MFC After: 3 days > Sponsored by: Netflix >=20 > Modified: > head/sys/dev/nvme/nvme.h > head/sys/dev/nvme/nvme_util.c As I remember _Static_assert is from C11, not the older C99. As I understand head/sys/dev/nvme/nvme.h use by C++ code could now reject attempts to use _Static_assert . There have been at least one old bugzilla report for such. An example is 205453 (back around 2015-Dec). =46rom back then: > # more main.cc > #include "/usr/include/sys/cdefs.h" > _Static_assert(1,"Test"); > int main(void) > { > return 0; > } >=20 > For example: >=20 > # g++49 main.cc > main.cc:2:15: error: expected constructor, destructor, or type = conversion before '(' token > _Static_assert(1,"Test"); > . . . > g++49, g++5, and powerpc64-portbld-freebsd11.0-g++ all reject the = above source the same way that libcxxrt/guard.cc compiles are rejected = during powerpc64-portbld-freebsd11.0-g++ based buildworld lib32 -m32 = compiles.=20 >=20 > gcc49, gcc5, and powerpc64-portbld-freebsd11.0-gcc all accept the = above instead (when in main.c instead of main.cc so it is handle as C = code), with or without the include. _Static_assert is specific to C11 = and is not part of C++. It takes explicit definitions to make the syntax = acceptable as C++. >=20 > Note: clang++ (3.7) accepts the use of the C11 _Static_assert, with or = without the include, going well outside the C++ language definition. >=20 > . . . >=20 > Fixed in r297299 . (The context was a C++ file head/contrib/libcxxrt/guard.cc so C++'s static_assert was used instead and -std=3Dc++11 was added for the library in question [libcxxrt].) Unless head/sys/dev/nvme/nvme.h is not to be used from C++ code: use of _Static_assert in the header would appear to be a problem. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Fri Aug 25 07:14:59 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8C8ECDF1711; Fri, 25 Aug 2017 07:14:59 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (xvm-110-62.dc2.ghst.net [46.226.110.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "theravensnest.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2E146763B3; Fri, 25 Aug 2017 07:14:57 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from [192.168.1.65] (host86-138-54-151.range86-138.btcentralplus.com [86.138.54.151]) (authenticated bits=0) by theravensnest.org (8.15.2/8.15.2) with ESMTPSA id v7P7EkFL066989 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 25 Aug 2017 07:14:48 GMT (envelope-from theraven@FreeBSD.org) X-Authentication-Warning: d60e724c-75b0-4b63-9702-f4a9d2bf6793: Host host86-138-54-151.range86-138.btcentralplus.com [86.138.54.151] claimed to be [192.168.1.65] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: svn commit: r322875 - head/sys/dev/nvme From: David Chisnall In-Reply-To: <1C5A448F-C91A-4599-8500-E4E46E6F5205@dsl-only.net> Date: Fri, 25 Aug 2017 08:14:41 +0100 Cc: imp@FreeBSD.org, svn-src-head@freebsd.org, FreeBSD Current , FreeBSD-STABLE Mailing List , freebsd-hackers Content-Transfer-Encoding: quoted-printable Message-Id: References: <1C5A448F-C91A-4599-8500-E4E46E6F5205@dsl-only.net> To: Mark Millard X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 07:14:59 -0000 On 25 Aug 2017, at 07:32, Mark Millard wrote: >=20 > As I remember _Static_assert is from C11, not > the older C99. In pre-C11 dialects of C, _Static_assert is an identifier reserved for = the implementation. sys/cdefs.h defines it to generate a zero-length = array if the condition is true or a negative-length array if it is = false, emulating the behaviour (though giving less helpful error = messages) >=20 > As I understand head/sys/dev/nvme/nvme.h use by > C++ code could now reject attempts to use > _Static_assert . In C++, _Static_assert is an identifier reserved for the implementation, = but in C++11 or newer static_assert is a keyword. sys/cdefs.h defines = _Static_assert to static_assert for newer versions of C++ and defines it = to the C-before-11-compatible version for C++-before-11. TL;DR: We have gone to a lot of effort to ensure that these keywords = work in all C/C++ dialects, please use them, please report bugs if you = find a case where they don=E2=80=99t work. David From owner-freebsd-hackers@freebsd.org Fri Aug 25 07:15:01 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9EF94DF1720 for ; Fri, 25 Aug 2017 07:15:01 +0000 (UTC) (envelope-from ed@nuxi.nl) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 65091763B9 for ; Fri, 25 Aug 2017 07:15:01 +0000 (UTC) (envelope-from ed@nuxi.nl) Received: by mail-yw0-x22f.google.com with SMTP id x21so8899700ywg.2 for ; Fri, 25 Aug 2017 00:15:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nuxi-nl.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=g2DTfZoMebmJh2RzdfhBmnMV+mEIa9ANAGkPWa8fN18=; b=XdY6n85AI4F+VOihOJ9lUK4Ie6b2nk7NcO7w2tFYbOTDeIyJIkLgCGxOM6/n7R5Ywb PG6AxXf0Pj+9ZeMaAR9c5KKPvTcGBSeqPkFgoPrs53CizcMMFLf8IwDPEoL0ARH2w5jk sDWxqL+ijG/b7pLNE3AMIrDFoxJK9rLsob+4CKWWcIk6O0jCZk+Aqk9RVHbMTwO1wXgf oQIgsa91jTimPBkVGRM2i4sG5jvutXbvyK3GmAR/T4T8fDYOUyFgfbT80oNstaUkFbk6 TeJSrUFe04sk+EDIaRP5niElUNLLDQZdfmwd6jZlp0EyZcu7eFxKrHi6W0OYEqYhWC+p pJ6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=g2DTfZoMebmJh2RzdfhBmnMV+mEIa9ANAGkPWa8fN18=; b=ZZCGnxKQTmIUQA5RpREi9p6Fw90sMrMD71QXReDe0MSh2tlEXu8IsV9smh9YTJv7BC UbW3G03En0m0itvJRGic+4VtctLZ2FNs4O+u5UeVVXCbkYXECS9iJbN7FusMv2ODBV0J drcA33qWAcw/dDlkXNkPpGZXy8tqwybdYL+FgsmKdHoQxx9RfP++sKg/7+i0+Tiuf3DK QW/82siZy0NbJwlc9hPbJcVxbMtJJ1S2G9hND6aSxAzFEa4lJnibGW0YXLcocaMrAJAE UBcbHHkiHIlozP3z/hlbq2xWAemuqgrl/ZdyoFYuyu2nIi5kgZf+H8TBTmzKqiQjvdKA 9tKw== X-Gm-Message-State: AHYfb5in1CXWSZlYwKM/Pc4Il1fQyOPPfmYN40SRiUnLb5kwO7YMFcvx 2dLpw8x6I3H3ipzokxSscgvEd0kpKxKh X-Received: by 10.129.44.85 with SMTP id s82mr7075965yws.254.1503645300382; Fri, 25 Aug 2017 00:15:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.227.193 with HTTP; Fri, 25 Aug 2017 00:14:29 -0700 (PDT) In-Reply-To: <1C5A448F-C91A-4599-8500-E4E46E6F5205@dsl-only.net> References: <1C5A448F-C91A-4599-8500-E4E46E6F5205@dsl-only.net> From: Ed Schouten Date: Fri, 25 Aug 2017 09:14:29 +0200 Message-ID: Subject: Re: svn commit: r322875 - head/sys/dev/nvme To: Mark Millard Cc: Warner Losh , svn-src-head@freebsd.org, FreeBSD Current , FreeBSD-STABLE Mailing List , freebsd-hackers Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 07:15:01 -0000 2017-08-25 8:32 GMT+02:00 Mark Millard : >> # g++49 main.cc >> main.cc:2:15: error: expected constructor, destructor, or type conversion before '(' token >> _Static_assert(1,"Test"); Yeah, that's because GCC is such a pain in the neck compiler that it doesn't want to expose these C11 keywords when building C++, even though they are in the reserved namespace (_[A-Z]). GCC would be permitted to expose these and still comply to standards. Doing so would make things so much easier for operating system implementors, like us. Clang does get it right, in my opinion. We should just extend to define _Static_assert() when using GCC in C++ mode (if we're not doing so already). -- Ed Schouten Nuxi, 's-Hertogenbosch, the Netherlands KvK-nr.: 62051717 From owner-freebsd-hackers@freebsd.org Fri Aug 25 07:46:55 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6215FDF231F for ; Fri, 25 Aug 2017 07:46:55 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-57.reflexion.net [208.70.210.57]) (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 144F777576 for ; Fri, 25 Aug 2017 07:46:54 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 18416 invoked from network); 25 Aug 2017 07:46:53 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 25 Aug 2017 07:46:53 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.2) with SMTP; Fri, 25 Aug 2017 03:46:53 -0400 (EDT) Received: (qmail 18096 invoked from network); 25 Aug 2017 07:46:53 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 25 Aug 2017 07:46:53 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id E0223EC901F; Fri, 25 Aug 2017 00:46:51 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: svn commit: r322875 - head/sys/dev/nvme From: Mark Millard In-Reply-To: Date: Fri, 25 Aug 2017 00:46:50 -0700 Cc: imp@FreeBSD.org, svn-src-head@freebsd.org, FreeBSD Current , FreeBSD-STABLE Mailing List , freebsd-hackers Content-Transfer-Encoding: quoted-printable Message-Id: References: <1C5A448F-C91A-4599-8500-E4E46E6F5205@dsl-only.net> To: David Chisnall X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 07:46:55 -0000 On 2017-Aug-25, at 12:14 AM, David Chisnall = wrote: > On 25 Aug 2017, at 07:32, Mark Millard wrote: >>=20 >> As I remember _Static_assert is from C11, not >> the older C99. >=20 > In pre-C11 dialects of C, _Static_assert is an identifier reserved for = the implementation. sys/cdefs.h defines it to generate a zero-length = array if the condition is true or a negative-length array if it is = false, emulating the behaviour (though giving less helpful error = messages) >=20 >>=20 >> As I understand head/sys/dev/nvme/nvme.h use by >> C++ code could now reject attempts to use >> _Static_assert . >=20 > In C++, _Static_assert is an identifier reserved for the = implementation, but in C++11 or newer static_assert is a keyword. = sys/cdefs.h defines _Static_assert to static_assert for newer versions = of C++ and defines it to the C-before-11-compatible version for = C++-before-11. >=20 > TL;DR: We have gone to a lot of effort to ensure that these keywords = work in all C/C++ dialects, please use them, please report bugs if you = find a case where they don=E2=80=99t work. It appears that at least 11.1-STABLE -r322807 does not handle -std=3Dc++98 styles of use of _Static_assert for g++7 in that g++7 reports an error: # uname -apKU FreeBSD hzFreeBSD11S 11.1-STABLE FreeBSD 11.1-STABLE r322807 amd64 = amd64 1101501 1101501 # more main.cc #include "/usr/include/sys/cdefs.h" _Static_assert(1,"Test"); int main(void) { return 0; } # g++7 -std=3Dc++98 main.cc main.cc:2:15: error: expected constructor, destructor, or type = conversion before '(' token _Static_assert(1,"Test"); ^ So it appears that as stands the _Static_assert implementation requires a more modern C++ standard vintage. With the likes of -Wpedantic clang++ from 11.1-STABLE -r322807 reports a warning: # clang++ -Wpedantic -std=3Dc++11 main.cc main.cc:2:1: warning: _Static_assert is a C11-specific feature = [-Wc11-extensions] _Static_assert(1,"Test"); ^ 1 warning generated. # clang++ -Wpedantic -std=3Dc++98 main.cc In file included from main.cc:1: /usr/include/sys/cdefs.h:852:27: warning: variadic macros are a C99 = feature [-Wvariadic-macros] #define __locks_exclusive(...) \ ^ . . . (more such macro reports) . . . main.cc:2:1: warning: _Static_assert is a C11-specific feature = [-Wc11-extensions] _Static_assert(1,"Test"); ^ 11 warnings generated. By contrast "g++7 -Wpedantic -std=3Dc++11 main.cc" is silent about it. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Fri Aug 25 12:54:09 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A4528DD7FB7 for ; Fri, 25 Aug 2017 12:54:09 +0000 (UTC) (envelope-from ed@nuxi.nl) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::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 5DDFF69F for ; Fri, 25 Aug 2017 12:54:09 +0000 (UTC) (envelope-from ed@nuxi.nl) Received: by mail-yw0-x22c.google.com with SMTP id s143so12383096ywg.0 for ; Fri, 25 Aug 2017 05:54:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nuxi-nl.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RIu2rjYI7wcozGH8zPBapRW1RXz24zKOdJ0SEla9VO0=; b=VGSa58wBffidV+vkXuVAs7kQ3orFskTbPu5WSJVn+GeOPGZ0sl6OS+9VIUSRCpKPRm 6XY3g+0vvg8N/bdl10M9IODLxGR/jGKwxZ7GEooeDWPzF3bOZnnb0OQGsrOxMivNjyOe w1joFEQ7JZ7Zy4pkcvdcTr2ukO+J+jUgm/F/Zq4jswabyGL5FWwg9jHDlkxpyFUXEEp8 Jp1IB+3D/b4+WdmiNV0jmHHL4KwNPge3ENtTcGdjP/yOd7WRWVhP/qfWw3vlPJnhG9wv Nax1IkkAHwooSTXdS5C/I1/dNQVMvjXKFv6KY+c+MDuEEYXXY5PoFdkNNYt2vwRWjAH5 ecYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RIu2rjYI7wcozGH8zPBapRW1RXz24zKOdJ0SEla9VO0=; b=Zczp+zmzpyMcnffRBLngxD9Ii0dw8j4mt2Nktx3Xi82OJ66dUZaTt32nJ63efVIeQO +YvZF6DYWSoqdt3GDufvCDzNJvqBmw68lE1DFesQX+r8wyyBqWFGdaJsRPRUmD+DufFl +h5WUPzUGcBC8Jw6chS1Qg5LgDU3MMOJCczSs9jGDS+dd1d9f2iaG0krzwnHIBUf69Kv fw/5Gh83RCCbUWlT2YUd9VaTPag30dI6+M9RZPFqW65u2kQ+LYSeySwmUK9mT6IcQSnz wf5v042BtIUaBV7xWGeEV7K6YJFk8ppSdj9I/MwmUHzv9ltT4FwIranhDwMT0X41tCcT QVZA== X-Gm-Message-State: AHYfb5grXS9vOG6uOvsISGh8HfugefADfYJdj+JwUAG3jjy8CUdzn5C8 BamVq8lzkcHb6lW5SifBl+uSTsrWhNBY X-Received: by 10.129.84.6 with SMTP id i6mr8156070ywb.203.1503665648453; Fri, 25 Aug 2017 05:54:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.227.193 with HTTP; Fri, 25 Aug 2017 05:53:37 -0700 (PDT) In-Reply-To: References: <1C5A448F-C91A-4599-8500-E4E46E6F5205@dsl-only.net> From: Ed Schouten Date: Fri, 25 Aug 2017 14:53:37 +0200 Message-ID: Subject: Re: svn commit: r322875 - head/sys/dev/nvme To: Mark Millard Cc: David Chisnall , Warner Losh , svn-src-head@freebsd.org, FreeBSD Current , FreeBSD-STABLE Mailing List , freebsd-hackers Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 12:54:09 -0000 2017-08-25 9:46 GMT+02:00 Mark Millard : > It appears that at least 11.1-STABLE -r322807 does not handle > -std=c++98 styles of use of _Static_assert for g++7 in that > g++7 reports an error: Maybe we need to do something like this? Index: sys/sys/cdefs.h =================================================================== --- sys/sys/cdefs.h (revision 322887) +++ sys/sys/cdefs.h (working copy) @@ -294,7 +294,7 @@ #if (defined(__cplusplus) && __cplusplus >= 201103L) || \ __has_extension(cxx_static_assert) #define _Static_assert(x, y) static_assert(x, y) -#elif __GNUC_PREREQ__(4,6) +#elif __GNUC_PREREQ__(4,6) && !defined(__cplusplus) /* Nothing, gcc 4.6 and higher has _Static_assert built-in */ #elif defined(__COUNTER__) #define _Static_assert(x, y) __Static_assert(x, __COUNTER__) -- Ed Schouten Nuxi, 's-Hertogenbosch, the Netherlands KvK-nr.: 62051717 From owner-freebsd-hackers@freebsd.org Fri Aug 25 15:10:44 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 93347DDA706 for ; Fri, 25 Aug 2017 15:10:44 +0000 (UTC) (envelope-from fernando.apesteguia@gmail.com) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1279B63C00; Fri, 25 Aug 2017 15:10:44 +0000 (UTC) (envelope-from fernando.apesteguia@gmail.com) Received: by mail-lf0-x22f.google.com with SMTP id d202so229242lfd.5; Fri, 25 Aug 2017 08:10:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=4NvZlriYrt7fWlht9Ru4Y12EcqDsGieHkfLPiUM1wwM=; b=jxghPk7OlM6T2j5B1Yr6JNUAYf/OZvym8W8c+vTrOKDGZ/CPgXE1b30vaXYYCw+A+3 nLiMHEVOlGXWSoWO+qoCX/YJlAzFZxatrMiTIl35eG1OAl8NQp7uGvXshCj+YG/qYov2 BYTGBKCTVsV54m+tJm+nsSTbUBuk+0DbXvVucEjrZkRRoLB1HCoIJpusMCIYdkD0vzEC lH3EyLqkFIZGnCq+8sjoesv5E7f0920xVb1VwAK8P0ipa48iOIpPoVYdoKXpkVicM2IR l0vlJ/BmpFTN52ecNf/7CPtT+nna4rVdbaUQLuJvw5oaGklc+R2sFym5uEYP/UM2GPZD wVnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=4NvZlriYrt7fWlht9Ru4Y12EcqDsGieHkfLPiUM1wwM=; b=du/nXQGrSwVwBtNC8fVTTVR5f6OXsOB1ZPvDM44bIV+VN1fEwdXxa5tFVhqEIBuC0r 2PxS1wlBMZ4muZNMAOIcoK3uD4MVJ7WOfTR5kcJ5hvYiwLM8hPDYyKjoMD/74C+C7D26 rY4nGaSPE7bmQU5YTg3Lo4v4+jYc37Nj2oz7zkiV8HgNju1AxyFQDAxq2SxJ5CYeCYch YkeGCSR2TH6q3qScSky8j+IGtdIvdjYDv08c8LenyuCoaFW4BRPIhn9+RHRUCCUzy5th bwpqUm/GhwzIReWo8J++EjzAKIBvYV1Of5CQPsl9yXynpGqzJkC86UqCgfurfePOM0oe y3rw== X-Gm-Message-State: AHYfb5gK2jX7JU2yrlj44F3T8Luu7R5l7GjaHNsCTIFvBe8L5EjgN88k dpsckTwVOJYr8ie0Qzz4oaf+31xpKA== X-Received: by 10.25.209.148 with SMTP id i142mr3300190lfg.135.1503673840635; Fri, 25 Aug 2017 08:10:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.21.225 with HTTP; Fri, 25 Aug 2017 08:10:39 -0700 (PDT) In-Reply-To: References: <71697463-4E52-4B46-B60B-00BDD87D8A2C@FreeBSD.org> From: =?UTF-8?Q?Fernando_Apestegu=C3=ADa?= Date: Fri, 25 Aug 2017 17:10:39 +0200 Message-ID: Subject: Re: Runaway process in -CURRENT To: Dimitry Andric Cc: FreeBSD Hackers , Ed Maste , Benjamin Kramer , Hans Wennborg Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 15:10:44 -0000 On Thu, Aug 24, 2017 at 8:27 PM, Fernando Apestegu=C3=ADa wrote: > On Thu, Aug 24, 2017 at 8:15 PM, Dimitry Andric wrote: >> On 24 Aug 2017, at 16:42, Fernando Apestegu=C3=ADa wrote: >>> >>> On Thu, Aug 24, 2017 at 11:14 AM, Fernando Apestegu=C3=ADa >>> wrote: >> ... >>> Just for the record, I got another email. Log URL: >>> >>> http://beefy11.nyi.freebsd.org/data/head-i386-default/p448640_s322824/l= ogs/stepcode-0.8_1.log >> ... >>> schemas/sdai_wip210e3/CMakeFiles/sdai_wip210e3.dir/SdaiAll.cc.o -MF >>> schemas/sdai_wip210e3/CMakeFiles/sdai_wip210e3.dir/SdaiAll.cc.o.d -o >>> schemas/sdai_wip210e3/CMakeFiles/sdai_wip210e3.dir/SdaiAll.cc.o -c >>> schemas/sdai_wip210e3/SdaiAll.cc >>> =3D=3D=3D=3D>> Killing runaway build after 7200 seconds with no output >> >> Hm, I had not noticed two facts, one being that there are a great many >> copies of SdaiAll.cc files, which all seem to be generated, and the >> other that this is occurring on i386. There are also other generated >> files, and specifically the compstructs.cc files can take extremely long >> to compile. >> >> On amd64, the longest compile time in the whole port is ~185 seconds, >> for a generated file of ~28000 lines: >> >> time lines filename >> =3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D >> 184.90 28345 schemas/sdai_wip210e3/compstructs.cc >> 115.08 103 schemas/sdai_ap239/SdaiAP239_PRODUCT_LIFE_CYCLE_SUPPORT_= ARM_LF_unity_types.cc >> 110.00 440 schemas/sdai_cd209/SdaiAP209_MULTIDISCIPLINARY_ANALYSIS_= AND_DESIGN_MIM_LF_unity_types.cc >> 106.70 292 schemas/sdai_wip210e3/SdaiAP210_ELECTRONIC_ASSEMBLY_INTE= RCONNECT_AND_PACKAGING_DESIGN_MIM_LF_unity_types.cc >> 90.73 290 schemas/sdai_cd242/SdaiAP242_MANAGED_MODEL_BASED_3D_ENGI= NEERING_MIM_LF_unity_types.cc >> 88.77 2232 schemas/sdai_cd209/SdaiAP209_MULTIDISCIPLINARY_ANALYSIS_= AND_DESIGN_MIM_LF_unity_entities.cc >> 81.87 2174 schemas/sdai_wip210e3/SdaiAP210_ELECTRONIC_ASSEMBLY_INTE= RCONNECT_AND_PACKAGING_DESIGN_MIM_LF_unity_entities.cc >> 73.92 19658 schemas/sdai_cd209/compstructs.cc >> 64.82 1734 schemas/sdai_cd242/SdaiAP242_MANAGED_MODEL_BASED_3D_ENGI= NEERING_MIM_LF_unity_entities.cc >> 61.42 189 schemas/sdai_ap210e2/SdaiAP210_ELECTRONIC_ASSEMBLY_INTER= CONNECT_AND_PACKAGING_DESIGN_MIM_LF_unity_types.cc >> >> On i386, this time is enormously increased, especially for the files >> with lots of lines: >> >> time lines filename >> =3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D >> 4809.23 28345 schemas/sdai_wip210e3/compstructs.cc >> 2164.37 19658 schemas/sdai_cd209/compstructs.cc >> 2056.54 15806 schemas/sdai_ap210e2/compstructs.cc >> 1545.19 16679 schemas/sdai_cd242/compstructs.cc >> 446.49 7667 schemas/sdai_ap203e2/compstructs.cc >> 273.96 6297 schemas/sdai_ap214e3/compstructs.cc >> 187.16 103 schemas/sdai_ap239/SdaiAP239_PRODUCT_LIFE_CYCLE_SUPPORT_= ARM_LF_unity_types.cc >> 163.39 440 schemas/sdai_cd209/SdaiAP209_MULTIDISCIPLINARY_ANALYSIS_= AND_DESIGN_MIM_LF_unity_types.cc >> 130.02 2232 schemas/sdai_cd209/SdaiAP209_MULTIDISCIPLINARY_ANALYSIS_= AND_DESIGN_MIM_LF_unity_entities.cc >> 122.15 290 schemas/sdai_cd242/SdaiAP242_MANAGED_MODEL_BASED_3D_ENGI= NEERING_MIM_LF_unity_types.cc >> > > I did some tests: > > -CURRENT (i326) in VirtualBox, 1 CPU, 8Gb RAM > > cd /usr/ports/cad/stepcode && time make > > * gcc 6.4.0 > > real 27m17.867s > user 50m.0.428s > sys 2m47.619 > > > * clang38 > > real 18m28.996s > user 33m22.790s > sys 1m22.711s > > * clang 5.0.0 > > It takes a lot of time compiling > schemas/sdai_{wip210e3,ap210e2}/SdaiAll.cc and other SdaAll.cc files. > It's still compiling after several hours. > > >> The compstructs.cc and SdaiAll.cc files contain *extremely* large >> generated functions, in most cases embodying the whole file, even. It >> seems that this is the cause for the long compile times. A test case >> tarball with the preprocessed version of the top compstructs.cc file, >> and a shell script to run it, is here: >> http://www.andric.com/freebsd/clang/stepcode.tar.xz >> >> With clang 4.0.0, the compile times are more at the level of the amd64 >> builds, even on i386. So this regressed somewhere along the way to >> 5.0.0. I will have to try to find out where, to see if there is an >> existing bug report or workaround. >> >> Note that in r321664, about three weeks ago, I already committed a >> couple of upstream fixes for some situations where compile times could >> get excessive (see also https://bugs.llvm.org/show_bug.cgi?id=3D33900), >> but it doesn't seem to have helped in this case. >> >> As a quick workaround, the port can be modified to compile these files >> using a lower optimization level. If -O1 is used for the longest case, >> e.g. schemas/sdai_wip210e3/compstructs.cc, the compile time drops down >> to ~30s. I don't think it will matter very much for the speed or size >> of the output. > > I'll have a look at this. Is this problem going to be reported upstream? > > Thanks! > >> >> -Dimitry >> From owner-freebsd-hackers@freebsd.org Fri Aug 25 15:12:42 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0F0DFDDA92D for ; Fri, 25 Aug 2017 15:12:42 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (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 C6F4863F6E for ; Fri, 25 Aug 2017 15:12:41 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22a.google.com with SMTP id f1so444371ith.0 for ; Fri, 25 Aug 2017 08:12:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=E3xfF4Q2s6msYkkCE1FuFmrVUvuChhx2V/2ZfJvFHq4=; b=YVCmy/ZTBfOo0O2YdHvZ0lqjpdYR/blwvNydjoDTbYcZh++P+BeubBJ3O9HuyImSUj 1pe6wjTaNoWqqBQQ/aLOzGxQw6upomuvW8dtYlB8fbPvXMGyO9t26CbAIO4z6B/8e832 Fasx6d3RIjPfRtz9eHkWkZ7dmDTPpxJH0ymBQecbUMIh3H7fGopfuj5CD3+gUAvLKPfd IiaxAqEJ4Y4GMaX/zLuwIESUWNDjszbBjJiEvRw8w+cTpZk0QV3Rj3getpWt9DGGz+sA mPbVP9WH6BAsgsWIgU1iPfTJ3t6+lQkCfUWDE4T5xm9RMqHKdt1rMBm/2478BEojKgq9 yUaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=E3xfF4Q2s6msYkkCE1FuFmrVUvuChhx2V/2ZfJvFHq4=; b=s88mNQzf16tvwxfWM4jaL68AduiWeT6M3p90FqRyCv7Ok3iSdX8HtxK49cDtPt+Ahr RWJaapBbNW2Nvkol5TGIX0aQ9D9eKkhvMurg+mGde749Trlbd3Y1UFWruSploQMt5jpi aTNX5+HJQFTKrTyuP/xRM5Uy2bWNAaz2U5KvnV2OTo3pe4pTJiG1OoZKg+pwQHemq6U3 4FEfcnLtJfNdvkfIMfHSaYlG4XBxmco6j4Y1bY4CXv8wZJYLQq+rQg1GTmZ/8k5O3DKL aCpWlxOm1K+mCSZn/v+9+slNFHE79Ub02lWR5sIX8IytRyS6HAxdhlHHffUwnsekPB5K u+dA== X-Gm-Message-State: AHYfb5gslhv3Vs/dMtUg115zhiMk9YXSkKhNddKrKpQtMFmgwRo2IAI9 MgeuWWwT9xj6vdVKFivZ3hF1dzdjpfIg X-Received: by 10.36.159.194 with SMTP id c185mr2158592ite.31.1503673961110; Fri, 25 Aug 2017 08:12:41 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.10.71 with HTTP; Fri, 25 Aug 2017 08:12:40 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:c525:dd46:ae7:666a] In-Reply-To: References: <1C5A448F-C91A-4599-8500-E4E46E6F5205@dsl-only.net> From: Warner Losh Date: Fri, 25 Aug 2017 09:12:40 -0600 X-Google-Sender-Auth: _kxfuPSK-xI_oIiFfngz2VSJxlU Message-ID: Subject: Re: svn commit: r322875 - head/sys/dev/nvme To: Ed Schouten Cc: Mark Millard , David Chisnall , Warner Losh , "svn-src-head@freebsd.org" , FreeBSD Current , FreeBSD-STABLE Mailing List , freebsd-hackers Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 15:12:42 -0000 On Fri, Aug 25, 2017 at 6:53 AM, Ed Schouten wrote: > 2017-08-25 9:46 GMT+02:00 Mark Millard : > > It appears that at least 11.1-STABLE -r322807 does not handle > > -std=c++98 styles of use of _Static_assert for g++7 in that > > g++7 reports an error: > > Maybe we need to do something like this? > > Index: sys/sys/cdefs.h > =================================================================== > --- sys/sys/cdefs.h (revision 322887) > +++ sys/sys/cdefs.h (working copy) > @@ -294,7 +294,7 @@ > #if (defined(__cplusplus) && __cplusplus >= 201103L) || \ > __has_extension(cxx_static_assert) > #define _Static_assert(x, y) static_assert(x, y) > -#elif __GNUC_PREREQ__(4,6) > +#elif __GNUC_PREREQ__(4,6) && !defined(__cplusplus) > /* Nothing, gcc 4.6 and higher has _Static_assert built-in */ > #elif defined(__COUNTER__) > #define _Static_assert(x, y) __Static_assert(x, __COUNTER__) This looks good to my eye, but my level of C++ pedantic knowledge is suboptimal. Warner From owner-freebsd-hackers@freebsd.org Fri Aug 25 18:50:15 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 15F16DDEE86 for ; Fri, 25 Aug 2017 18:50:15 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C17066C32D; Fri, 25 Aug 2017 18:50:14 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:470:7a58::d91a:7f20:7200:12cd] (unknown [IPv6:2001:470:7a58:0:d91a:7f20:7200:12cd]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 6FA2030D4D; Fri, 25 Aug 2017 20:50:06 +0200 (CEST) From: Dimitry Andric Message-Id: <8B71A339-6053-4446-97C2-0EE4572F87D5@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_10AF3C5E-2F9A-4327-9A41-440792349881"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Runaway process in -CURRENT Date: Fri, 25 Aug 2017 20:49:57 +0200 In-Reply-To: Cc: FreeBSD Hackers , Ed Maste , Benjamin Kramer , Hans Wennborg To: =?utf-8?Q?Fernando_Apestegu=C3=ADa?= References: <71697463-4E52-4B46-B60B-00BDD87D8A2C@FreeBSD.org> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 18:50:15 -0000 --Apple-Mail=_10AF3C5E-2F9A-4327-9A41-440792349881 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 25 Aug 2017, at 17:10, Fernando Apestegu=C3=ADa = wrote: >=20 > On Thu, Aug 24, 2017 at 8:27 PM, Fernando Apestegu=C3=ADa > wrote: ... >>> As a quick workaround, the port can be modified to compile these = files >>> using a lower optimization level. If -O1 is used for the longest = case, >>> e.g. schemas/sdai_wip210e3/compstructs.cc, the compile time drops = down >>> to ~30s. I don't think it will matter very much for the speed or = size >>> of the output. >>=20 >> I'll have a look at this. >=20 > Is this problem going to be reported upstream? This took some time, I reported it here: https://bugs.llvm.org/show_bug.cgi?id=3D34326 -Dimitry --Apple-Mail=_10AF3C5E-2F9A-4327-9A41-440792349881 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.1 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCWaBxVQAKCRCwXqMKLiCW o3wxAJ4/KQd8zXFWNMyhX8h/XsBhFPdOLgCg+zOP4uwuhXnRKDQbSWbT1w+wXZU= =HsHL -----END PGP SIGNATURE----- --Apple-Mail=_10AF3C5E-2F9A-4327-9A41-440792349881-- From owner-freebsd-hackers@freebsd.org Sat Aug 26 09:25:48 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 995BDDF1FB8 for ; Sat, 26 Aug 2017 09:25:48 +0000 (UTC) (envelope-from fernando.apesteguia@gmail.com) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (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 0B31664883; Sat, 26 Aug 2017 09:25:48 +0000 (UTC) (envelope-from fernando.apesteguia@gmail.com) Received: by mail-lf0-x22a.google.com with SMTP id d202so6943137lfd.5; Sat, 26 Aug 2017 02:25:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5QO3KIcWCCK6AXN44UCMy1n6uj47SJ3xuDTzwNS0MDg=; b=o8NEQJJZOkDHY8Mh92QOYAugqK11C4MC6mHB7q5Xe6//i3Ngt7Z4FDF2lfPnOQLMxv u5xPPfVHy4PV1iz+liKPRn75t17e0CwKWQ0DPb0LCqLNx0O4KXZjecBv450a44JZUf/V kYDqhkM7C+j6A6buoVwcCxqsuZYCJzIN7KQGpXHKDdkBwlyB7akI5bb4u/PgMKKBZ+i0 zGcno3eme5L+Z/FEDWkYM36zttxK8NP/EhLdamz06JwWveTaZkgIradAZx/leA1K1Ww5 Fx2KHi6Q1BrvNabMdnjidPRK1r6fBYHKlzI7qNgUspSv4fdCli2W5oD+EVVZG19uHYj0 8mEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5QO3KIcWCCK6AXN44UCMy1n6uj47SJ3xuDTzwNS0MDg=; b=f+Omie0Zx6fxhufTqNmOzWAUX9+8+Ia3Cl8RO71EBcIhiOhZv/SXBO0gstppcYcrs2 /d4/+soT3qe7Xx3D/N2oVzbR3lqkvJJFU1BM5mpjxUg9C0ZOasgeqVnSI2pZsJVlSwUb xfItFACGPqF1U7N9R+Jb45S1u80HK2nCqQpcAMNGdCcwe7iFlB5MlkqJKiTzYSNTbEs6 JIWFIm6ZeIW0TDfwH6g7aVMwkv7mYD3yu0mNewnizE/Ril/fowYi+pHE1CXiZsEqPGAK Zkp1PMNAd2i+iXanO7wD0T6Abw928J5UDYIZMQLRFbYtJntQdPMhscBlOFoKJVJEJyVk Wakw== X-Gm-Message-State: AHYfb5hY9PIp2k7WAVKhWk+xNNU4PpuJykDLt9JDr7XgqHpLoXqs5dSt Ttnt6KTTX9tq2e8vr8mkbVktjRbygA== X-Received: by 10.25.209.148 with SMTP id i142mr347481lfg.135.1503739545225; Sat, 26 Aug 2017 02:25:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.21.225 with HTTP; Sat, 26 Aug 2017 02:25:43 -0700 (PDT) Received: by 10.25.21.225 with HTTP; Sat, 26 Aug 2017 02:25:43 -0700 (PDT) In-Reply-To: <8B71A339-6053-4446-97C2-0EE4572F87D5@FreeBSD.org> References: <71697463-4E52-4B46-B60B-00BDD87D8A2C@FreeBSD.org> <8B71A339-6053-4446-97C2-0EE4572F87D5@FreeBSD.org> From: =?UTF-8?Q?Fernando_Apestegu=C3=ADa?= Date: Sat, 26 Aug 2017 11:25:43 +0200 Message-ID: Subject: Re: Runaway process in -CURRENT To: Dimitry Andric Cc: Benjamin Kramer , Ed Maste , FreeBSD Hackers , Hans Wennborg Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Aug 2017 09:25:48 -0000 El 25 ago. 2017 20:50, "Dimitry Andric" escribi=C3=B3: On 25 Aug 2017, at 17:10, Fernando Apestegu=C3=ADa wrote: > > On Thu, Aug 24, 2017 at 8:27 PM, Fernando Apestegu=C3=ADa > wrote: ... >>> As a quick workaround, the port can be modified to compile these files >>> using a lower optimization level. If -O1 is used for the longest case, >>> e.g. schemas/sdai_wip210e3/compstructs.cc, the compile time drops down >>> to ~30s. I don't think it will matter very much for the speed or size >>> of the output. >> >> I'll have a look at this. > > Is this problem going to be reported upstream? This took some time, I reported it here: https://bugs.llvm.org/show_bug.cgi?id=3D34326 Thank you very much. I'll test the port again once the fix from upstream is imported into FreeBSD. In the meantime I'll submit an update with a workaround. Cheers. -Dimitry From owner-freebsd-hackers@freebsd.org Sat Aug 26 09:41:12 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E73E5DF2376; Sat, 26 Aug 2017 09:41:12 +0000 (UTC) (envelope-from aijazbaig1@gmail.com) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::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 B1FE464FD6; Sat, 26 Aug 2017 09:41:12 +0000 (UTC) (envelope-from aijazbaig1@gmail.com) Received: by mail-it0-x236.google.com with SMTP id p10so1915387ite.1; Sat, 26 Aug 2017 02:41:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=d36P6VVSR5aLOrJmhbi/gz7DOhvKJk37ANldDW3ERKY=; b=GUCi41n1PD+g3NzZc4MhxPym3o8mUmw9mWpM+7Qgb68v4NF42qQIzl1AGpopeR3riM 8WTGqPFDlyM3siZxv5nykB6NA3lZGdgplYCUv+Cwxcl8kd1eF5NdHu9kWP/TJnOV8R/+ zYlm4BDC/wfC7hLsoNmspUpiDkE6pZZTUpIR0sa3jFMFOazy/I33/rOf/OOsXe9GT89J 42xU4Vg/lm1Yg1J7cE5qxbOfzASKsxB5Ts6LZGxKTIFe7AzvXAKHqMjWmFU0IfwD7Omy xvpA3BnkPV909ccvVYpnfffkfoZgoNtX5zIjDbHoees58MJEPq06J2lxDdEfvfe/MfDv dvXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=d36P6VVSR5aLOrJmhbi/gz7DOhvKJk37ANldDW3ERKY=; b=fwmIwZ85GYEoDskoVYA1FF56RNYp7tzzb5VLz5qySgS56bwFLoLJeUlRNN9lxfy+ML kIKQJTKrjW7KA0gPcIGb12wye8iMd/IVQ4cX104o/URGPJOh31Cz4pjqww9x+g47lRE1 S2RgW2Sy/BJic5BG37GNE6IYhcmS9XSucoVd8heW0WOGOK5jCVOCqYjTvhuLxk3DW0tz aigJxLXpGgF5nc6WJG/BEi5ztw7lgh/T6qAdvNRy9Fphld4yYVMgWzlipsC5JwkMBqJi VnO0W+BPcncxFD9sP185ZENA4gxdYmq6atAmZSOlkxv6RKCLwHnI/mBtZDOHkJXFoR+l Q/rQ== X-Gm-Message-State: AHYfb5ica9s26Qpzslzb1P5bW+U7nvvwIiLCOWR1V8Y1HUTywcndmfJ7 gq3pDqj3tmwRm0+Ab85iIDxLkKzhfwur X-Received: by 10.107.187.135 with SMTP id l129mr1155689iof.122.1503740471956; Sat, 26 Aug 2017 02:41:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.2.22.66 with HTTP; Sat, 26 Aug 2017 02:41:11 -0700 (PDT) From: Aijaz Baig Date: Sat, 26 Aug 2017 15:11:11 +0530 Message-ID: Subject: Compiling the kernel using GCC To: FreeBSD Hackers , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Aug 2017 09:41:13 -0000 Has anyone been able to successfully compile the kernel using GCC as against CLANG the default compiler on most later versions of FreeBSD? I was able to successfully buildworld. After which I reboot and now /usr/bin/cc points to GCC as requested. However kernel fails to link Here is my src.conf: COPTFLAGS+= -O0 -pipe -Wno-attributes -Wno-redundant-decls WERROR="-Wno-error" WITHOUT_CLANG="yes" WITHOUT_CLANG_IS_CC="yes" WITHOUT_CLANG_BOOTSTRAP="yes" WITH_GCC_BOOTSTRAP="yes" WITH_GCC="yes" WITH_GNUCXX="yes" WITHOUT_JAIL="yes" WITHOUT_WIRELESS="yes" WITHOUT_WIRELESS_SUPPORT="yes" WITHOUT_WPA_SUPPLICANT_EAPOL="yes" WITHOUT_CDDL="yes" It fails here: >>> stage 3.1: building everything -------------------------------------------------------------- cd /usr/obj/usr/src/sys/AIJAZ-DEBUG; COMPILER_VERSION=40201 COMPILER_FEATURES= COMPILER_TYPE=gcc COMPILER_FREEBSD_VERSION=1200001 MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=amd64 MACHINE=amd64 CPUTYPE= CC="cc -isystem /usr/obj/usr/src/tmp/usr/include -L/usr/obj/usr/src/tmp/usr/lib -B/usr/obj/usr/src/tmp/usr/lib --sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin" CXX="c++ -isystem /usr/obj/usr/src/tmp/usr/include -L/usr/obj/usr/src/tmp/usr/lib -B/usr/obj/usr/src/tmp/usr/lib --sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin" CPP="cpp -isystem /usr/obj/usr/src/tmp/usr/include -L/usr/obj/usr/src/tmp/usr/lib -B/usr/obj/usr/src/tmp/usr/lib --sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin" AS="as" AR="ar" LD="ld" LLVM_LINK="" NM=nm OBJCOPY="objcopy" RANLIB=ranlib STRINGS= SIZE="size" INSTALL="sh /usr/src/tools/install.sh" PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin make -D KERNFAST -m /usr/src/share/mk KERNEL=kernel all -DNO_MODULES_OBJ linking kernel.full ck_array.o: In function `ck_cc_popcount': /usr/src/sys/contrib/ck/include/gcc/ck_cc.h:139: undefined reference to `__popcountdi2' ck_barrier_centralized.o: In function `ck_cc_popcount': /usr/src/sys/contrib/ck/include/gcc/ck_cc.h:139: undefined reference to `__popcountdi2' ck_barrier_combining.o: In function `ck_cc_popcount': /usr/src/sys/contrib/ck/include/gcc/ck_cc.h:139: undefined reference to `__popcountdi2' ck_barrier_dissemination.o: In function `ck_cc_popcount': /usr/src/sys/contrib/ck/include/gcc/ck_cc.h:139: undefined reference to `__popcountdi2' ck_barrier_mcs.o: In function `ck_cc_popcount': /usr/src/sys/contrib/ck/include/gcc/ck_cc.h:139: undefined reference to `__popcountdi2' ck_barrier_tournament.o:/usr/src/sys/contrib/ck/include/gcc/ck_cc.h:139: more undefined references to `__popcountdi2' follow *** Error code 1 Stop. make[2]: stopped in /usr/obj/usr/src/sys/AIJAZ-DEBUG *** Error code 1 Stop. make[1]: stopped in /usr/src *** Error code 1 Stop. make: stopped in /usr/src Is there something else I am missing? Aijaz Baig From owner-freebsd-hackers@freebsd.org Sat Aug 26 16:18:33 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 02734DD5463 for ; Sat, 26 Aug 2017 16:18:32 +0000 (UTC) (envelope-from daniel@roe.ch) Received: from schoggimuss.roe.ch (schoggimuss.roe.ch [IPv6:2a03:da40:0:35::10]) (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 B786E70768 for ; Sat, 26 Aug 2017 16:18:32 +0000 (UTC) (envelope-from daniel@roe.ch) Received: from daniel (ssh-from [178.197.225.197]) by schoggimuss.roe.ch (envelope-from ) with LOCAL id 1dldn2-0005d2-16 for freebsd-hackers@freebsd.org; Sat, 26 Aug 2017 18:18:28 +0200 Date: Sat, 26 Aug 2017 18:18:27 +0200 From: Daniel Roethlisberger To: freebsd-hackers@freebsd.org Subject: [PATCH] O_NOATIME support for open(2) Message-ID: <20170826161827.GA21456@schoggimuss.roe.ch> Mail-Followup-To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="45Z9DzgjV8m4Oswq" Content-Disposition: inline User-Agent: Mutt/1.8.3 (2017-05-23) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Aug 2017 16:18:33 -0000 --45Z9DzgjV8m4Oswq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I'm trying to implement O_NOATIME support for open(2) in order to provide a more elegant way for backup/archiving software to prevent atime clobbering. Except for a 2008 thread on this list I did not find any material; not sure if anybody is interested in this or if there are reasons why this was never implemented. The attached patch against 11.1 implements O_NOATIME support for open(2); it prevents read(2) and mmap(2) from clobbering atime if the file descriptor was opened with O_NOATIME. O_NOATIME is only permitted for root and the owner of the file. Currently it is only implemented for ufs/ffs. It seems to work for me but has not been extensively tested. I am interested in feedback from people who know their way around I/O and VFS code before I extend this to other file systems, make O_NOATIME tunable by fcntl(2), wire it to the Linux compat layer and write docs. Does the implementation look sane? Did I miss something important? Specifically, is there a better way to pass O_NOATIME into vm_mmap_vnode other than adding an additional boolean_t argument? I did not use an additional mmap flag because that would have required additional logic to prevent userland from passing the flag to the mmap syscall. Daniel -- Daniel Roethlisberger http://daniel.roe.ch/ --45Z9DzgjV8m4Oswq Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="onoatime-v2.diff" diff --git a/sys/kern/vfs_vnops.c b/sys/kern/vfs_vnops.c index 3138dda..2f75b2b 100644 --- a/sys/kern/vfs_vnops.c +++ b/sys/kern/vfs_vnops.c @@ -317,6 +317,8 @@ vn_open_vnode(struct vnode *vp, int fmode, struct ucred *cred, } if (fmode & FREAD) accmode |= VREAD; + if ((fmode & FNOATIME) && (fmode & FREAD)) + accmode |= VADMIN; if (fmode & FEXEC) accmode |= VEXEC; if ((fmode & O_APPEND) && (fmode & FWRITE)) @@ -798,6 +800,8 @@ vn_read(fp, uio, active_cred, flags, td) ioflag |= IO_NDELAY; if (fp->f_flag & O_DIRECT) ioflag |= IO_DIRECT; + if (fp->f_flag & FNOATIME) + ioflag |= IO_NOATIME; advice = get_advice(fp, uio); vn_lock(vp, LK_SHARED | LK_RETRY); @@ -2398,6 +2402,7 @@ vn_mmap(struct file *fp, vm_map_t map, vm_offset_t *addr, vm_size_t size, vm_object_t object; vm_prot_t maxprot; boolean_t writecounted; + boolean_t noatime; int error; #if defined(COMPAT_FREEBSD7) || defined(COMPAT_FREEBSD6) || \ @@ -2470,8 +2475,9 @@ vn_mmap(struct file *fp, vm_map_t map, vm_offset_t *addr, vm_size_t size, foff < 0 || foff > OFF_MAX - size) return (EINVAL); + noatime = fp->f_flag & FNOATIME; writecounted = FALSE; - error = vm_mmap_vnode(td, size, prot, &maxprot, &flags, vp, + error = vm_mmap_vnode(td, size, prot, &maxprot, &flags, vp, noatime, &foff, &object, &writecounted); if (error != 0) return (error); diff --git a/sys/sys/fcntl.h b/sys/sys/fcntl.h index d1d0062..fbd2931 100644 --- a/sys/sys/fcntl.h +++ b/sys/sys/fcntl.h @@ -133,6 +133,11 @@ typedef __pid_t pid_t; #define O_VERIFY 0x00200000 /* open only after verification */ #endif +#define O_NOATIME 0x00400000 /* do not update atime */ +#ifdef _KERNEL +#define FNOATIME O_NOATIME +#endif + /* * XXX missing O_DSYNC, O_RSYNC. */ @@ -150,7 +155,7 @@ typedef __pid_t pid_t; #define OFLAGS(fflags) ((fflags) & O_EXEC ? (fflags) : (fflags) - 1) /* bits to save after open */ -#define FMASK (FREAD|FWRITE|FAPPEND|FASYNC|FFSYNC|FNONBLOCK|O_DIRECT|FEXEC) +#define FMASK (FREAD|FWRITE|FAPPEND|FASYNC|FFSYNC|FNONBLOCK|O_DIRECT|FEXEC|FNOATIME) /* bits settable by fcntl(F_SETFL, ...) */ #define FCNTLFLAGS (FAPPEND|FASYNC|FFSYNC|FNONBLOCK|FRDAHEAD|O_DIRECT) diff --git a/sys/sys/vnode.h b/sys/sys/vnode.h index dedbec6..28e0923 100644 --- a/sys/sys/vnode.h +++ b/sys/sys/vnode.h @@ -302,6 +302,7 @@ struct vattr { #define IO_INVAL 0x0040 /* invalidate after I/O */ #define IO_SYNC 0x0080 /* do I/O synchronously */ #define IO_DIRECT 0x0100 /* attempt to bypass buffer cache */ +#define IO_NOATIME 0x0200 /* do not update atime */ #define IO_EXT 0x0400 /* operate on external attributes */ #define IO_NORMAL 0x0800 /* operate on regular data */ #define IO_NOMACCHECK 0x1000 /* MAC checks unnecessary */ diff --git a/sys/ufs/ffs/ffs_vnops.c b/sys/ufs/ffs/ffs_vnops.c index b1de1b8..3067d2e 100644 --- a/sys/ufs/ffs/ffs_vnops.c +++ b/sys/ufs/ffs/ffs_vnops.c @@ -672,6 +672,7 @@ ffs_read(ap) if ((error == 0 || uio->uio_resid != orig_resid) && (vp->v_mount->mnt_flag & (MNT_NOATIME | MNT_RDONLY)) == 0 && + (ioflag & IO_NOATIME) == 0 && (ip->i_flag & IN_ACCESS) == 0) { VI_LOCK(vp); ip->i_flag |= IN_ACCESS; diff --git a/sys/vm/vm_extern.h b/sys/vm/vm_extern.h index c37973d..57503f9 100644 --- a/sys/vm/vm_extern.h +++ b/sys/vm/vm_extern.h @@ -94,7 +94,7 @@ int vm_mmap_to_errno(int rv); int vm_mmap_cdev(struct thread *, vm_size_t, vm_prot_t, vm_prot_t *, int *, struct cdev *, struct cdevsw *, vm_ooffset_t *, vm_object_t *); int vm_mmap_vnode(struct thread *, vm_size_t, vm_prot_t, vm_prot_t *, int *, - struct vnode *, vm_ooffset_t *, vm_object_t *, boolean_t *); + struct vnode *, boolean_t, vm_ooffset_t *, vm_object_t *, boolean_t *); void vm_set_page_size(void); void vm_sync_icache(vm_map_t, vm_offset_t, vm_size_t); typedef int (*pmap_pinit_t)(struct pmap *pmap); diff --git a/sys/vm/vm_mmap.c b/sys/vm/vm_mmap.c index d0f14f3..d1d5cab 100644 --- a/sys/vm/vm_mmap.c +++ b/sys/vm/vm_mmap.c @@ -1191,7 +1191,7 @@ kern_munlock(struct thread *td, uintptr_t addr0, size_t size) int vm_mmap_vnode(struct thread *td, vm_size_t objsize, vm_prot_t prot, vm_prot_t *maxprotp, int *flagsp, - struct vnode *vp, vm_ooffset_t *foffp, vm_object_t *objp, + struct vnode *vp, boolean_t noatime, vm_ooffset_t *foffp, vm_object_t *objp, boolean_t *writecounted) { struct vattr va; @@ -1283,7 +1283,8 @@ vm_mmap_vnode(struct thread *td, vm_size_t objsize, *objp = obj; *flagsp = flags; - vfs_mark_atime(vp, cred); + if (!noatime) + vfs_mark_atime(vp, cred); done: if (error != 0 && *writecounted) { @@ -1400,7 +1401,7 @@ vm_mmap(vm_map_t map, vm_offset_t *addr, vm_size_t size, vm_prot_t prot, } case OBJT_VNODE: error = vm_mmap_vnode(td, size, prot, &maxprot, &flags, - handle, &foff, &object, &writecounted); + handle, FALSE, &foff, &object, &writecounted); break; case OBJT_DEFAULT: if (handle == NULL) { --45Z9DzgjV8m4Oswq-- From owner-freebsd-hackers@freebsd.org Sat Aug 26 17:56:12 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2D63EDD6D3C for ; Sat, 26 Aug 2017 17:56:12 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B9D5772B8D for ; Sat, 26 Aug 2017 17:56:11 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v7QHu6a4062461 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 26 Aug 2017 20:56:06 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v7QHu6a4062461 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v7QHu6SZ062460 for freebsd-hackers@freebsd.org; Sat, 26 Aug 2017 20:56:06 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 26 Aug 2017 20:56:06 +0300 From: Konstantin Belousov To: freebsd-hackers@freebsd.org Subject: Re: [PATCH] O_NOATIME support for open(2) Message-ID: <20170826175606.GQ1700@kib.kiev.ua> References: <20170826161827.GA21456@schoggimuss.roe.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170826161827.GA21456@schoggimuss.roe.ch> User-Agent: Mutt/1.8.3 (2017-05-23) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Aug 2017 17:56:12 -0000 On Sat, Aug 26, 2017 at 06:18:27PM +0200, Daniel Roethlisberger wrote: > I'm trying to implement O_NOATIME support for open(2) in order to > provide a more elegant way for backup/archiving software to > prevent atime clobbering. Except for a 2008 thread on this list > I did not find any material; not sure if anybody is interested in > this or if there are reasons why this was never implemented. Please point out the thread, e.g. by providing a link to the first message in the thread in mailman archive. > > The attached patch against 11.1 implements O_NOATIME support for > open(2); it prevents read(2) and mmap(2) from clobbering atime if > the file descriptor was opened with O_NOATIME. O_NOATIME is only > permitted for root and the owner of the file. Currently it is > only implemented for ufs/ffs. It seems to work for me but has > not been extensively tested. What would happen when additional page-in occurs on the mmaped area ? > > I am interested in feedback from people who know their way around > I/O and VFS code before I extend this to other file systems, make > O_NOATIME tunable by fcntl(2), wire it to the Linux compat layer > and write docs. Does the implementation look sane? Did I miss > something important? > > Specifically, is there a better way to pass O_NOATIME into > vm_mmap_vnode other than adding an additional boolean_t argument? > I did not use an additional mmap flag because that would have > required additional logic to prevent userland from passing the > flag to the mmap syscall. If you need two booleans to the function, consider substituting the arguments with the single u_int flags, and define two flags, one for the writecounted, one for noatime.