From owner-freebsd-hackers@freebsd.org Sun Sep 9 01:38:51 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A37FE10811B6 for ; Sun, 9 Sep 2018 01:38:51 +0000 (UTC) (envelope-from rpp@ci.com.au) Received: from mippet.ci.com.au (mippet.ci.com.au [192.65.182.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mippet.ci.com.au", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E04FC80453 for ; Sun, 9 Sep 2018 01:38:49 +0000 (UTC) (envelope-from rpp@ci.com.au) Received: from mippet-2.ci.com.au (mippet-2.ci.com.au [192.168.1.254]) by mippet-dkim.ci.com.au (8.15.2/8.15.2/CE050417) with ESMTPS id w891YwOH003500 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Sun, 9 Sep 2018 11:34:59 +1000 (AEST) (envelope-from rpp@ci.com.au) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ci.com.au; s=jun2016; t=1536456899; bh=8fe6dA6VVtdqX0jRJpOWXMgBCqerHEI39IjvpILIhJQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=qytOB/hwxhBXvr5AZmPCStDfNCJVCeLv3eBthdn3vqZq6y1PlqBDRroHRZu7QBkH6 +mql95Yts2r57m9iw19AZdvnPDYjvcuGAPNQjMmnCUzcNE6HJxtRPdxZm/jjGzRUm1 V5txMAFFSAR88NlBLf9UHyyvVFFQf9WvQslk2mdhM5Z+vCpVuqEDSgpaCgfFUj68sY FCEQUSP8TH/ymPx/cBILweobrJiMf3zpzkuogDYcVlxZ6StG1ocjGCB5R+dVgSo6c/ wo0zCm2XNftY4V9QiqwaYViqsW6zEDbZvC1btKAL/sbihhhRYadqbeeI9OASz+t41b hKJCTpA+Pv75Q== Received: from jodi.ci.com.au (jodi.ci.com.au [192.168.1.21]) by mippet.ci.com.au (8.15.2/8.15.2/CE120917) with ESMTPS id w891YwIY003497 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 9 Sep 2018 11:34:58 +1000 (AEST) (envelope-from rpp@ci.com.au) Received: from jodi.ci.com.au (jodi.ci.com.au [192.168.1.21]) by jodi.ci.com.au (8.15.2/8.15.2) with SMTP id w891YwCf026561; Sun, 9 Sep 2018 11:34:58 +1000 (AEST) (envelope-from rpp@ci.com.au) Date: Sun, 9 Sep 2018 11:34:58 +1000 From: Richard Perini To: Matt Churchyard Cc: freebsd-hackers@freebsd.org Subject: Re: Getting valid JSON output with xo(1) Message-ID: <20180909013458.GA26493@jodi.ci.com.au> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2018 01:38:51 -0000 On Sat, Sep 08, 2018 at 02:41:10PM +0100, Matt Churchyard wrote: > Hello, > > Sorry if this is the wrong list, I wasn't sure which was the most > appropriate. > > I've been asked to look at generating machine output from vm-bhyve using > xo(1), and though it would be an interesting task. However, I'm coming > across a few issues getting valid output. I've reduced my code down to the > following example - [ ... ] I've never used xo but have used "jo" to perform similar tasks. https://github.com/jpmens/jo Its JSON only. I don't think there's a port for it, but it builds simply on FreeBSD-10 through FreeBSD-12. Richard Perini Ramico Australia Pty Ltd Sydney, Australia rpp@ci.com.au +61 2 9552 5500 ----------------------------------------------------------------------------- "The difference between theory and practice is that in theory there is no difference, but in practice there is" From owner-freebsd-hackers@freebsd.org Sun Sep 9 07:25:51 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 72730108DBE5 for ; Sun, 9 Sep 2018 07:25:51 +0000 (UTC) (envelope-from yuripv@yuripv.net) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (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 1D0648A306 for ; Sun, 9 Sep 2018 07:25:50 +0000 (UTC) (envelope-from yuripv@yuripv.net) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 69957219FE for ; Sun, 9 Sep 2018 03:25:50 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Sun, 09 Sep 2018 03:25:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yuripv.net; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=WGQTiIs7TMsCvKhumwdvMurRz86D8BgFMuGFsFunemY=; b=sqogr4e7 D/zYero/sLPFp1ky/DnB6RT6mPJJncuAZfleNGjwaFLHzZbtTTyAnn/2X/uAefT7 sllISho+BaC+x+w7RvEdbpxs5o2JB2Q7XG+BMvqMXf896xm2V2yAwavFjPlemaMp AD5GTckNNz/nMztfxJPpN101Sk+dGqJL8tKC+zdQRFLkHi2ENtF3d7HjVbfozm0e /UOn2jdBMdTdZVMUwBG2zQ70JrGUI++pnzupUu0w/d1uHvf1tAqGxl5RU1OzzYBS zuKkoUV7mEKHDtn8H+MQK1Uytr7kw3LprvVrCojIpnEL9J6szbxCIXsflejnihDQ JkLGXC/Wn98WlA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=WGQTiIs7TMsCvKhumwdvMurRz86D8 BgFMuGFsFunemY=; b=IyzaSWFzJk7/wZMbp3ttty/3JTQyhfL1zaY7Ldo2j4B3I r6ZAWE9LQKKWLSpfNLAGvbrKRZi9QtXTgFBoz3RDZHgH4Hi/1hwwcNMBCzunZwcA p6UM38ya3qjjfAHvIZP7zdJ8fBc3rCiFVtetLdMiOhmjVAQiaUpIBH/qblgAWHQx s9gWaPtgPdvUJ2mDq7vqCs/PwrSW9rW6McDH0sF93h7IYtrhsoK5h7Gdt0Zlq1e4 aYRArbbcQWT3/+3cAqPQXRTwxNshcEuW2sqqrAC5Qf5Noajs0HJiJTsCLrlxnrY3 sNwg3vKVBNScrhyyFw6pcmzdAxSdIGCFG+DEu0jXA== X-ME-Proxy: X-ME-Sender: Received: from [192.168.1.2] (unknown [62.183.126.215]) by mail.messagingengine.com (Postfix) with ESMTPA id A699810293 for ; Sun, 9 Sep 2018 03:25:49 -0400 (EDT) To: freebsd-hackers From: Yuri Pankov Subject: acpi, pci, spibus -- tying it all together Message-ID: <30e41db8-a56d-e916-0490-7e184063a811@yuripv.net> Date: Sun, 9 Sep 2018 10:25:44 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2018 07:25:51 -0000 I have modified intelspi to attach to SPI master (Sunrise Point-H Serial IO SPI) located on pci bus, and on attach I have the spibus0 and spibus1 buses added. As spibus is not self-enumerating, the only way to find the slave device I need is via acpi bus probe, that works, but I don't see a way to make it a child of spibus1 (where it's located). In ACPI terms it looks like the below (from DSDT): ... \_SB_.PCI0.SPI0 "Device (SPI0)" \_SB_.PCI0.SPI1 "Device (SPI1)" ... Scope (SPI1) { Device (SPIT) { ...here comes all the data we need, including the ACPI ID we can probe... } } ... I hope that made at least some sense. And the question is if there any existing way of tying it all together, and adding that slave device to the spibus1 (which only knows about hinted children at the moment)? From owner-freebsd-hackers@freebsd.org Sun Sep 9 09:23:07 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E9A8F108FE80 for ; Sun, 9 Sep 2018 09:23:06 +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 688D38CF09 for ; Sun, 9 Sep 2018 09:23:06 +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 w899Mtqo033323 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 9 Sep 2018 12:22:58 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w899Mtqo033323 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w899MtZA033322; Sun, 9 Sep 2018 12:22:55 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 9 Sep 2018 12:22:55 +0300 From: Konstantin Belousov To: Yuri Pankov Cc: freebsd-hackers Subject: Re: acpi, pci, spibus -- tying it all together Message-ID: <20180909092255.GM3161@kib.kiev.ua> References: <30e41db8-a56d-e916-0490-7e184063a811@yuripv.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30e41db8-a56d-e916-0490-7e184063a811@yuripv.net> User-Agent: Mutt/1.10.1 (2018-07-13) 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.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2018 09:23:07 -0000 On Sun, Sep 09, 2018 at 10:25:44AM +0300, Yuri Pankov wrote: > I have modified intelspi to attach to SPI master (Sunrise Point-H Serial > IO SPI) located on pci bus, and on attach I have the spibus0 and spibus1 > buses added. > > As spibus is not self-enumerating, the only way to find the slave device > I need is via acpi bus probe, that works, but I don't see a way to make > it a child of spibus1 (where it's located). > > In ACPI terms it looks like the below (from DSDT): > > ... > \_SB_.PCI0.SPI0 "Device (SPI0)" > \_SB_.PCI0.SPI1 "Device (SPI1)" > ... > Scope (SPI1) { > Device (SPIT) { > ...here comes all the data we need, > including the ACPI ID we can probe... > } > } > ... > > I hope that made at least some sense. And the question is if there any > existing way of tying it all together, and adding that slave device to > the spibus1 (which only knows about hinted children at the moment)? I had very similar situation where I wrote NVDIMM driver. The suggestion I got was to implement DEVICE_IDENTIFY() method. It gets the driver_t and the parent bus device_t arguments. In the method, you create children' device_t, iterating over the ACPI enumerated entries. Practically, you would use acpica AcpiWalkNamespace(ACPI_TYPE_DEVICE, ...) function and call BUS_ADD_CHILD() when needed. Set the ACPI handle for the created child. [Get the Intel' ACPICA reference manual to understand the KPI]. Then probe does nothing, and attach verifies against the handle. You can see that in https://kib.kiev.ua/kib/nvdimm.7.patch nvdimm_identify(), nvdimm_foreach_acpi(), and nvdimm_create_dev(). From owner-freebsd-hackers@freebsd.org Sun Sep 9 14:10:05 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8BE7A1095915 for ; Sun, 9 Sep 2018 14:10:05 +0000 (UTC) (envelope-from churchers@gmail.com) Received: from mail-vk1-xa29.google.com (mail-vk1-xa29.google.com [IPv6:2607:f8b0:4864:20::a29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2ACB573FB1 for ; Sun, 9 Sep 2018 14:10:05 +0000 (UTC) (envelope-from churchers@gmail.com) Received: by mail-vk1-xa29.google.com with SMTP id h200-v6so2436949vke.5 for ; Sun, 09 Sep 2018 07:10:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=9DEQscg7gz8bOH4pgylb9XeZAlIyncgJPBPxyEUShug=; b=HeWtcGtPiDSJqXX0IckwesVFZO4yzQEPazJh6c+tIibqzptSy/qIdTW0+ZNQww2uGf gY6ws2bYfGovbJpBcCHMyD8/T9m8CHXnKftvj7pMkSZY5GzeMzVIogBMcSvoWbpTRjks cnhrLUC+vxM6HHdqmcYGj3GEljDEezT3or8I23KOtA/hm+zk7wKQNcLeGaZT6VGM5YnE 6v5f0ItLiUpN/wGFRnpDMuii/MvPpGto8HLAqDWUvtxaar1PxB7xUm5P6ZaDaMcfcz/8 5Ng6gMbRmbGGRv+/hHjE4vNrqV3BKlLl7lD0PB4u/qGZmj1u4ZyboZC/Q0ruAYXlnZd9 ZrgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=9DEQscg7gz8bOH4pgylb9XeZAlIyncgJPBPxyEUShug=; b=bimShaP+3nXVm1DEcAHOeZ4/5+8xkqrJEftKhJkRjyigKWThR0AK8Sb7giUUQWwR2h jhzUao9qITn5Gtps0PdLp+iG2CfuZVPXNlkl/jf3CeOpHeKN4o3lAo+J/FOjwij+jf7j FK9Jd9tYNA7sedTrJx7zlcolFg1DNKIudqRmhaOfTyz943gHEz4mV5Z2iHSr1UE11SfJ 6TXKXBh1fc8t8l8oGijbJHTyfatbpBeZ1D0dTirmIlT820CtmwBYuFZKkOeziciH+Ho1 iqgZXIpSaSSuVqmk1EGAhTglhPGpSR0nGADvEyKsTvtESBZML2tnNyu3XwVFkSwTTCzg kKxg== X-Gm-Message-State: APzg51BtpTByNS3TRbEFuGdHAoJJrkoES/IcSJjXAYV6c8DRR0Imr/Fa Pr29BNP+4gMzwgv/+p5K+TXi3kwAQ5Kx+hAmIkKKig== X-Google-Smtp-Source: ANB0Vdb3bKRJKkEXkXskm/lCw9hKf/uzwe8qQOIBOwdRUp2QqAXr5vu9/Um54fgkmnqlkf/qXxMw5j4+/kNPDlKKR+o= X-Received: by 2002:a1f:2047:: with SMTP id g68-v6mr5254322vkg.103.1536502204493; Sun, 09 Sep 2018 07:10:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Matt Churchyard Date: Sun, 9 Sep 2018 15:10:09 +0100 Message-ID: Subject: Fwd: Getting valid JSON output with xo(1) To: freebsd-hackers@freebsd.org X-Mailman-Approved-At: Sun, 09 Sep 2018 14:23:24 +0000 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2018 14:10:05 -0000 Hi Stefan, I did include the commands used to generate the sample output in my first message. I am using the xo(1) utility, not libxo directly. I did mention this might not be the right list (you've obviously assumed I'm directly using libxo), but it does seem to me this is more an issue with the xo utility, rather than just a usage error. I've since looked further into the libxo documentation, and as you suggest, it does seem that I need to be using the xo_open_list/xo_close_list functions to generate the right output. However, these are not exposed via xo(1). The documentation for xo_open_list describes how it is used to create lists of individual entities, whereas the "l" modifier (which is all I can access via xo(1)) creates "leaf lists", which are only for single values. As such, it seems there's a big hole in the functionality of xo(1), meaning it can only really be used to create very simple JSON documents. As I mentioned in my first message, it looks like xo(1) could do with some way to open/close lists, similar to the --open/--close options, and a way to specify that a single call should be output as a part of a list. Matt On Sun, Sep 9, 2018 at 10:29 AM Stefan Esser wrote: > Am 08.09.18 um 15:41 schrieb Matt Churchyard: > > Hello, > > > > Sorry if this is the wrong list, I wasn't sure which was the most > > appropriate. > > > > I've been asked to look at generating machine output from vm-bhyve using > > xo(1), and though it would be an interesting task. However, I'm coming > > across a few issues getting valid output. I've reduced my code down to > the > > following example - > > > > xo -pX --open bhyve/machines > > xo -pX --depth 2 --wrap machine "{:name},{:memory}" test1 2GB > > xo -pX --depth 2 --wrap machine "{:name},{:memory}" test2 4GB > > xo -pX --close bhyve/machines > > > > This produces the following XML output which looks good - > > > > > > > > > > test1 > > 2GB > > > > > > test2 > > 4GB > > > > > > > > > > If I choose HTML output I get the following invalid output which is > missing > > closing tags. > > > >
> >
test1
> >
,
> >
2GB
> >
> >
test2
> >
,
> >
4GB
> > > > This can be fixed by adding "\n" to the end of the format lines, which > may > > be required, but it seems strange that I can so easily generate broken > > output. I'm not too bothered about HTML though as it seems fairly > useless, > > JSON is my biggest issue - > It would be a lot easier to help if you posted a (stripped down) version of > the code used to generate this output. > > You are not correctly using the list functions, and thus the outer lists > are > not closed. I had suggested a better syntax and semantics for these > functions > to automatically take care of such cases, but they were rejected by the > main > libxo author. > > Every xo_open_list() must be matched by a matching xo_close_list() and you > may need to use another type (list, container, instance) than you currently > do. > > Did you run xolint to test your usage of xo functions? > > Regards, STefan > From owner-freebsd-hackers@freebsd.org Sun Sep 9 16:13:20 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1BC971097FC0 for ; Sun, 9 Sep 2018 16:13:20 +0000 (UTC) (envelope-from se@freebsd.org) Received: from mailout10.t-online.de (mailout10.t-online.de [194.25.134.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9C352771AD for ; Sun, 9 Sep 2018 16:13:19 +0000 (UTC) (envelope-from se@freebsd.org) Received: from fwd11.aul.t-online.de (fwd11.aul.t-online.de [172.20.27.152]) by mailout10.t-online.de (Postfix) with SMTP id EA2D241F02AF; Sun, 9 Sep 2018 18:13:11 +0200 (CEST) Received: from Stefans-MBP-LAN.fritz.box (TD4y4yZaYhWmllzK7eg2RqibhcA8S40ULB5Gb5Vp8+ByWpWGOYFYvOtS3T-9AjTgSM@[93.200.59.58]) by fwd11.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384 encrypted) esmtp id 1fz2Kh-1sL3tA0; Sun, 9 Sep 2018 18:13:07 +0200 Subject: Re: Getting valid JSON output with xo(1) To: Matt Churchyard , freebsd-hackers@freebsd.org References: From: Stefan Esser Openpgp: preference=signencrypt Autocrypt: addr=se@freebsd.org; prefer-encrypt=mutual; keydata= xsBNBFVxiRIBCADOLNOZBsqlplHUQ3tG782FNtVT33rQli9EjNt2fhFERHIo4NxHlWBpHLnU b0s4L/eItx7au0i7Gegv01A9LUMwOnAc9EFAm4EW3Wmoa6MYrcP7xDClohg/Y69f7SNpEs3x YATBy+L6NzWZbJjZXD4vqPgZSDuMcLU7BEdJf0f+6h1BJPnGuwHpsSdnnMrZeIM8xQ8PPUVQ L0GZkVojHgNUngJH6e21qDrud0BkdiBcij0M3TCP4GQrJ/YMdurfc8mhueLpwGR2U1W8TYB7 4UY+NLw0McThOCLCxXflIeF/Y7jSB0zxzvb/H3LWkodUTkV57yX9IbUAGA5RKRg9zsUtABEB AAHNKVN0ZWZhbiBFw59lciAoWWFob28hKSA8c3QuZXNzZXJAeWFob28uZGU+wsCWBBMBCgBA AhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AWIQSjceplnAvsyCtxUxNH67XvWv31RAUC WvLvqwUJCyUBEwAKCRBH67XvWv31REySCACc6vqcSFQCRyBRc2CV5ZBjbbnTy7VBoXbUS3/c 4Hn8I0YQ39q7//2z8vYsgLeM1mMXL4PUIU/0f0dBAFBLpxV7bntGzyCJls6SeGS/qcQKhqaI 6I7NcWg8OkIJIhUL6q238cS1ql9pU65fyHe0PP8JS08m81PDpX2/4wTE6h2jgYUy55eXRzoF MEjr1S8SSnidsBem27o7iWu9ltJsUtE86071iZlLzbuHv2nvucrjAV9cK9tHrxYT/YiY8QhT L48iWj2xIjLjg1ebmgIFZ2k881we/KTIoUugqOOR1gDSc4qwM8CA388cN3frjtl98CwhAT5T UV8tIDqri+/Z1AKwzsBNBFVxiRIBCACxI/aglzGVbnI6XHd0MTP05VK/fJub4hHdc+LQpz1M kVnCAhFbY9oecTB/togdKtfiloavjbFrb0nJhJnx57K+3SdSuu+znaQ4SlWiZOtXnkbpRWNU eMm+gtTDMSvloGAfr76RtFHskdDOLgXsHD70bKuMhlBxUCrSwGzHaD00q8iQPhJZ5itb3WPq z3B4IjiDAWTO2obD1wtAvSuHuUj/XJRsiKDKW3x13cfavkad81bZW4cpNwUv8XHLv/vaZPSA ly+hkY7NrDZydMMXVNQ7AJQufWuTJ0q7sImRcEZ5EIa98esJPey4O7C0vY405wjeyxpVZkpq ThDMurqtQFn1ABEBAAHCwHwEGAEKACYCGwwWIQSjceplnAvsyCtxUxNH67XvWv31RAUCWvLv qwUJCyUBGQAKCRBH67XvWv31RLnrB/9gzcRlpx71sDMosoZULWn7wysBJ/8AIEfIByRaHQe3 pn/KwE57pB+zFbbQqB7YzeZb7/UUgR4zU2ZbOcEfwDZcHUbj0B3fGRsS3t0uiLlAd8w0sBZb SxrqzjdpDjIbOZkxssqUmvrsN67UG1AFWH9aD24keBS7YjPBS8hLxPeYV+Xz6vUL8fRZje/Z JgiBMIwyj6g2lH/zkdnxBdC0iG1xxJOLTaghMMeQyCdH6ef8+VMyAlAJsMckbOTvx63tY8z7 DFcrnTJfbe1EziRilVsEaK8tTzJzhcTfos+f3eBYWEilxe5HzIhYKJeC7lmsSUcGwa6+9VRg a0ctmi9Z8OgX Message-ID: <228b2a88-6134-c8c2-a28d-cb09cbc03ef6@freebsd.org> Date: Sun, 9 Sep 2018 18:13:04 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit X-ID: TD4y4yZaYhWmllzK7eg2RqibhcA8S40ULB5Gb5Vp8+ByWpWGOYFYvOtS3T-9AjTgSM X-TOI-MSGID: 3bc294a9-15da-4ede-8e06-901306ab1095 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2018 16:13:20 -0000 Am 09.09.18 um 16:10 schrieb Matt Churchyard: > Hi Stefan, > > I did include the commands used to generate the sample output in my first > message. I am using the xo(1) utility, not libxo directly. I did mention > this might not be the right list (you've obviously assumed I'm directly > using libxo), but it does seem to me this is more an issue with the xo > utility, rather than just a usage error. Hi Matt, I'm sorry - you are of course right and there was everything required to reproduce the effect in your previous mail ... > I've since looked further into the libxo documentation, and as you suggest, > it does seem that I need to be using the xo_open_list/xo_close_list > functions to generate the right output. However, these are not exposed via > xo(1). The documentation for xo_open_list describes how it is used to > create lists of individual entities, whereas the "l" modifier (which is all > I can access via xo(1)) creates "leaf lists", which are only for single > values. As such, it seems there's a big hole in the functionality of xo(1), > meaning it can only really be used to create very simple JSON documents. The following code fragment in libxo.c does suppress the terminating new-line character on purpose if depth != 0: case XO_STYLE_JSON: pre_nl = XOF_ISSET(xop, XOF_PRETTY) ? "\n" : ""; ppn = (xop->xo_depth <= 1) ? "\n" : ""; xo_depth_change(xop, name, -1, -1, XSS_CLOSE_CONTAINER, 0); rc = xo_printf(xop, "%s%*s}%s", pre_nl, xo_indent(xop), "", ppn); xop->xo_stack[xop->xo_depth].xs_flags |= XSF_NOT_FIRST; break; The reason appears to be, that closing the outer level construct will print a new-line before other text. If you omit the second "xo --wrap", everything will look OK. And if you test with --depth 0, you'll see that the output is actually terminated with a new-line. > As I mentioned in my first message, it looks like xo(1) could do with some > way to open/close lists, similar to the --open/--close options, and a way > to specify that a single call should be output as a part of a list. I do not see a better solution than adding an "echo" command between calls to "xo --wrap", as you already mentioned as a work-around. This is simpler than adding list_open/close functions and it has the same effect, if you know that you are emitting JSON. Best regards, STefan From owner-freebsd-hackers@freebsd.org Sun Sep 9 22:44:18 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D456310A1167 for ; Sun, 9 Sep 2018 22:44:17 +0000 (UTC) (envelope-from yuripv@yuripv.net) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 78B3784707 for ; Sun, 9 Sep 2018 22:44:17 +0000 (UTC) (envelope-from yuripv@yuripv.net) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailnew.nyi.internal (Postfix) with ESMTP id 26AF51DAE; Sun, 9 Sep 2018 18:44:11 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Sun, 09 Sep 2018 18:44:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yuripv.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=8opAWpZ8U6Cus0BSsaCba9kvlM40r twEG3mhCoAekkY=; b=xOpZeiASaXZNqh3Po3+bH3Cu949DAGDnp0qelqYGWjTfP UeaDuAej4+2B5516VKLSUhsxwAl0GvHpoMDHs/CWCfz8801kI0dOUydGeEWuTWZd +C+qakj3C4kC1X6xZe3dkMETSs9oN2o1VHZumGfzM/aGWWWqIs1HW6cjjoyEYJnt 4m/6MsCS/X7YqtuWSZMibsG8uAnkrM/Xb7h2wG9NvzEdiKSUxwnbfiQ9bPm2lZTQ Ct6wOnDojl1cV94wGi02ZowxZFvHTVSZmIXoD2hI/6j16gbrQELmGfYXClYze7Jk SjZKLy1CvRcr00bUVDqJIFd1kGcyrjtHqpd3PbCig== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=8opAWp Z8U6Cus0BSsaCba9kvlM40rtwEG3mhCoAekkY=; b=gqfIlYTeFR2/Y+FCyM21RD qRJhWBeFIMNyapKC1vVg6bA+NT6bWAx+p3pmRRTLwJS1+na6qyEj8fdhPM0StD0X ELRtinvqRFBbIuRuv9DcCpLZbuUNA5jl8zlQ7s9HC6REXNkvFVnepqLcpeWk7h9i 38M6RiVPFX7gOkpet1QL8mJ9LwhazByGjnGE2gjRPSJyo4wO//RUZyl/RJllDwek NpGNkRxsjxv3EAkvYK3VOUw50+zjQynyO0ed4a9UyeX05+PwQmU85F/3OMRMAM1R EG6eEShp8za965pW65VpI1T+QSNr7Z6Yd3dsv72Q+R4U9KMG5KCkjwJCUrPhMCRw == X-ME-Proxy: X-ME-Sender: Received: from [192.168.1.2] (unknown [94.233.225.59]) by mail.messagingengine.com (Postfix) with ESMTPA id B1FEB10297; Sun, 9 Sep 2018 18:44:09 -0400 (EDT) Subject: Re: acpi, pci, spibus -- tying it all together To: Konstantin Belousov Cc: freebsd-hackers References: <30e41db8-a56d-e916-0490-7e184063a811@yuripv.net> <20180909092255.GM3161@kib.kiev.ua> From: Yuri Pankov Message-ID: <4770e2e5-ebb7-8740-dd7c-e16998bef970@yuripv.net> Date: Mon, 10 Sep 2018 01:44:08 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <20180909092255.GM3161@kib.kiev.ua> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2018 22:44:18 -0000 Konstantin Belousov wrote: > On Sun, Sep 09, 2018 at 10:25:44AM +0300, Yuri Pankov wrote: >> I have modified intelspi to attach to SPI master (Sunrise Point-H Serial >> IO SPI) located on pci bus, and on attach I have the spibus0 and spibus1 >> buses added. >> >> As spibus is not self-enumerating, the only way to find the slave device >> I need is via acpi bus probe, that works, but I don't see a way to make >> it a child of spibus1 (where it's located). >> >> In ACPI terms it looks like the below (from DSDT): >> >> ... >> \_SB_.PCI0.SPI0 "Device (SPI0)" >> \_SB_.PCI0.SPI1 "Device (SPI1)" >> ... >> Scope (SPI1) { >> Device (SPIT) { >> ...here comes all the data we need, >> including the ACPI ID we can probe... >> } >> } >> ... >> >> I hope that made at least some sense. And the question is if there any >> existing way of tying it all together, and adding that slave device to >> the spibus1 (which only knows about hinted children at the moment)? > > I had very similar situation where I wrote NVDIMM driver. > > The suggestion I got was to implement DEVICE_IDENTIFY() method. It > gets the driver_t and the parent bus device_t arguments. In the method, > you create children' device_t, iterating over the ACPI enumerated entries. > Practically, you would use acpica AcpiWalkNamespace(ACPI_TYPE_DEVICE, ...) > function and call BUS_ADD_CHILD() when needed. Set the ACPI handle for > the created child. [Get the Intel' ACPICA reference manual to understand > the KPI]. > > Then probe does nothing, and attach verifies against the handle. > > You can see that in https://kib.kiev.ua/kib/nvdimm.7.patch > nvdimm_identify(), nvdimm_foreach_acpi(), and nvdimm_create_dev(). Thank you, it was helpful indeed, especially the walk part. From owner-freebsd-hackers@freebsd.org Mon Sep 10 00:40:02 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8CA1610A3A6B for ; Mon, 10 Sep 2018 00:40:02 +0000 (UTC) (envelope-from munro@penski.net) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1098E8884C for ; Mon, 10 Sep 2018 00:40:01 +0000 (UTC) (envelope-from munro@penski.net) Received: by mail-ed1-x530.google.com with SMTP id f38-v6so15199964edd.8 for ; Sun, 09 Sep 2018 17:40:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=penski-net.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=c8GmZGC5dphiWcLFg4DKMmnaFRpaAS+uPdjEVqyguVc=; b=lo2FV5hBPMHLvE9ZNMd/KkjsmOIvgPNi94+LRWY4l9REUQzp3dQkCe82q9QnwbOzVE CIUAB6XMWTz+UvBviUD5xFdukQSHrQXRtqbR70NdpayYbi6r/vcp6Wpsrlk/E4ARKED2 /9T46I38StpM3oF4MyiB1qPeJwyEYpVrtIzOMNzGgIS95UWpHq1grQsUbxxv2kpmQdwb W+E04RLz5njodfDC5+mFTbJOAgqTjvkHGz/IQCrgOor5OGX/CSqpOCvZdUaEI5uv2mRE Yc+K338OR8mzELg+e8tx7vo4fYLDqw1sl/VOQqxaZwz0CMCvyn9JwyUybHenO3ieHKAw 9Ldw== 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=c8GmZGC5dphiWcLFg4DKMmnaFRpaAS+uPdjEVqyguVc=; b=ZRqJn64dLnEQpGJc1sfYK1QYQU4m+qo0mvmS3fa1EVO/c9eHSA2YfrhII/UdMOS7Uh LnNXY+DDIk6eHtrcXTfLIAd8b8CM9c2mKeN9va2eOlQqNE3otm1G27afdQmCgleKXIdO DtWUuZOiuvDyMRhinIIREhWIc82SHXKaOd6xjjwGOaDX+AnARH+qXEiTd6sUod5pS9Ej kRNax7nenwPsg5KAPsIMmkgTbOmxoPHUaQKaeSfweIwmhTLmWqiUJK7Vwn4r6hvrZuDO 6wWJLznRTEWeHsb4ThRBNhaeERiogbiv62Sg3WGOzXHeSaEtxTTqJkLwbZ87YoEKpdSa CBFA== X-Gm-Message-State: APzg51CopLFzhuDI7tQG3GMNu/LnuhdtVhoGeI/jBRS1YPDainhmd7QA tKkj2ferDePQw01yWxLdGi4FYNdWD2qch9xxwOqH5CtSCk4= X-Google-Smtp-Source: ANB0Vdaql54FjMUanN2Yl98E2tvo4jTVkKNZaYSpxV5C2E4QtWCrqGKl9sSgzMiyHnaSNa9q73j9dnqTYR/gfGl3BsA= X-Received: by 2002:a50:f51b:: with SMTP id t27-v6mr20017345edm.235.1536540000422; Sun, 09 Sep 2018 17:40:00 -0700 (PDT) MIME-Version: 1.0 Sender: munro@penski.net Received: by 2002:aa7:d64c:0:0:0:0:0 with HTTP; Sun, 9 Sep 2018 17:39:59 -0700 (PDT) X-Originating-IP: [121.73.38.77] In-Reply-To: <1536416542111-0.post@n6.nabble.com> References: <1536416542111-0.post@n6.nabble.com> From: Thomas Munro Date: Mon, 10 Sep 2018 12:39:59 +1200 X-Google-Sender-Auth: ylNXnZkCx3LGM7ruEPUNv_ec3rQ Message-ID: Subject: Re: Tracking CLDR version in collation definitions To: yuripv Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2018 00:40:02 -0000 On 9 September 2018 at 02:22, yuripv wrote: > Hi Thomas, > > I think this makes perfect sense, yes, and not aware of any other way of > having the data version information. Thanks for the feedback. This is reassuring. Yeah I've looked around a bit. > There are some nits in the man page changes, but that can of course be taken > care of during review. Cool -- I will do some more work on this and post a differential. > A bigger question is backwards compatibility as you seem to be changing the > on-disk format -- I can't think of anything bad happening off the top of my > head, just wondering if you had some ideas on it. The on-disk format I propose is deliberately forwards AND backwards compatible. That region of the file is currently full of zeroes. If you call the new function for an older LC_COLLATE file, you just get an empty string. If you access a file that does have the new version using an older libc, it ignores that region of the file. From owner-freebsd-hackers@freebsd.org Mon Sep 10 00:47:00 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 83CCC10A3EEC for ; Mon, 10 Sep 2018 00:47:00 +0000 (UTC) (envelope-from munro@penski.net) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E934E88D80 for ; Mon, 10 Sep 2018 00:46:59 +0000 (UTC) (envelope-from munro@penski.net) Received: by mail-ed1-x536.google.com with SMTP id z27-v6so15223851edb.10 for ; Sun, 09 Sep 2018 17:46:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=penski-net.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=zz+MMCV3dzTYDF4nv+o7T4y4EgHWyqvxtVR5M8+RFmw=; b=bcGqs/vTfYqjS5Cxo1ZnBVGygoLTtYuP41Ulwp2QkcYcFHEeu08akyyZlBui9s00mG k+9st0a/aXaVNw9uUiW8/uHgmt+CkI0mgdENt3GMcLTcbQu16S38PHpmFva3Y4ryyt+0 Khe//zlDlle2lKLZr3CprcsMHzHT7hisAz6OL93vb7sfHb9LaZ9VvSQC9thi+qvJezPI 4ZRjHOxIkQafXD4WO0MmT07M4cDgtsDhVNsiKSlUAbEZ02L55UIQ3+2U2a8jLpv2WPM+ ksgzCIBAvk9L6ZigV6hpdvBP8WfeHP8Ki4a9gRRR/CacqhttFUj+zI8dCvjWXESknaQ9 VIWg== 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=zz+MMCV3dzTYDF4nv+o7T4y4EgHWyqvxtVR5M8+RFmw=; b=K1J0QqMIurtb3GE82pa875f3ZNfkrnQBYVCpp3YsFIS55NvnBVl0frIKoLHrFsuEwp buqGSD+ur2n4h6Dx+K3/pX1G8MEGbBxR9AIC6JryTgCUUXzgl0J/JNwTAqO0LmG61dEf hltoCp0Chku5sAQ8Gm5CrhVDQ+xccuTIVzUNDQF2Yd2RTLvCp806ZMTUPpa7gBpu2BEm RTcV1Cw09QGmSfSzdM/CNsIUhJRImbYgkk7UuFcGPfo+ufVN3JTRuQiDKzLo0uwX1Vor n6fZkCuZTLpCMWZ39Nyjtadapo9eAC28OVWHWtrjaqJmWHoncC6YNk//swx36jybX6sI BLNA== X-Gm-Message-State: APzg51CxBDA0/paWMssdWQMOCqin7rI4U9m4LmT1YnXtC4GQkA+KMP6h +vqki0KgKKpWrD5rGFDoEAh+LNyPMqYLe++KEljoOg== X-Google-Smtp-Source: ANB0Vdbhncx0qHxgV3ffSl5FYq9nhC8NBR2zjdgjqoLKs0J8c7cBzrePxJmV2aw7oVdEmRIaOGWEFtXVGvO8yGbl1Zk= X-Received: by 2002:a50:91da:: with SMTP id h26-v6mr20326792eda.87.1536540418791; Sun, 09 Sep 2018 17:46:58 -0700 (PDT) MIME-Version: 1.0 Sender: munro@penski.net Received: by 2002:aa7:d64c:0:0:0:0:0 with HTTP; Sun, 9 Sep 2018 17:46:58 -0700 (PDT) X-Originating-IP: [121.73.38.77] In-Reply-To: <20180908172819.GE3161@kib.kiev.ua> References: <1536416542111-0.post@n6.nabble.com> <20180908172819.GE3161@kib.kiev.ua> From: Thomas Munro Date: Mon, 10 Sep 2018 12:46:58 +1200 X-Google-Sender-Auth: NxUGYnyz1WEvPKIm0GxexmIShys Message-ID: Subject: Re: Tracking CLDR version in collation definitions To: Konstantin Belousov Cc: yuripv , freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2018 00:47:00 -0000 On 9 September 2018 at 05:28, Konstantin Belousov wrote: > On Sat, Sep 08, 2018 at 07:22:22AM -0700, yuripv wrote: >> Hi Thomas, >> >> I think this makes perfect sense, yes, and not aware of any other way of >> having the data version information. >> >> There are some nits in the man page changes, but that can of course be taken >> care of during review. > > At least, the new symbols must not go into the FBSD_1.3 namespace, but > into the current namespace of the HEAD at the tome of commit. I believe > it will be FBSD_1.6 when the patch has a chance to hit the tree. Thanks, I'll bear that in mind for the next revision. > I also think that more specific name, indicating that this is a FreeBSD > unique function, should be used. Yeah, I was wondering about that. This may sound a bit too ambitious, but my plan is to produce a working version in a real operating system, and then make a proposal the Austin Group for a future POSIX revision. From owner-freebsd-hackers@freebsd.org Mon Sep 10 08:58:37 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0392E1083BD9 for ; Mon, 10 Sep 2018 08:58:37 +0000 (UTC) (envelope-from sghctoma@gmail.com) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6AB9F76C9B for ; Mon, 10 Sep 2018 08:58:36 +0000 (UTC) (envelope-from sghctoma@gmail.com) Received: by mail-wr1-x431.google.com with SMTP id 20-v6so20987574wrb.12 for ; Mon, 10 Sep 2018 01:58:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:subject:message-id:mail-followup-to:mime-version :content-disposition:user-agent; bh=fbK8KO/TC71yUENviQCMDr9zd8Aw//3DeVbAwaojFug=; b=B6o5Dkq4sQjW5DSXsN+VeGdAMEdno2mwCLsUaxr/HpQzuLo5wBYgbCl/4iegRdzru+ 0GVnBRWXkrJD4/Z94nBqJ4Ab8amm7itbmZhoee8MLMP7r7tdQTIVXzPA1dbPEGE9oppx 9qaECgDuqZaviVvsmRaEc/4RHhlqsj0dRCfLV0RZE5f7r8Ej6YY52jOUZsw2KfqYPMGR Z7zZO7B3tj151eeZwPbx5aDYkKdnIMJF+vSAS+I7cDbnFGMlMJ/uOgLuWTmfzpVeJehU PPMhgE5dX9tpdCr/N9DhbS1eXOwh2vlNhwBbiPBiIqI5yCT0bo1QFJbWaOEsrXazK5Hg BtqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mail-followup-to :mime-version:content-disposition:user-agent; bh=fbK8KO/TC71yUENviQCMDr9zd8Aw//3DeVbAwaojFug=; b=HkCepBalxS2fQMSeDCZweqbSkxXDjDv1tIDcN0U/+sL9V03Gqvxm53d4lOZeWWrw+9 gGze9qS5C8cFZHGEwQxeVHbjPVJbQ3+xuy9hqvoAt9ioR5BveHRWXqRVsL/krBZlbXrW G0oKkK2Yez6bjJHhTrZ7PRyBBhwBvy93HfmT+lJr3mfnodwbxM0UsKDFrblllK7K52WG pJYTlCt+RSPCXiVvCoO3VWsOmSmIdg70Y2DAMUrMgYayLewSy9Hl1QTKCN/cu878oEr8 uiZY+gMW2okBtPUl6Evcz4I61VC5Um5eP4f1yJiEnR9+kwQzDkcBuElKRA4eeRZblTRA hkEg== X-Gm-Message-State: APzg51BKiNAGpfnBz1z99fkx0KTHBY66rGafhkQxudXEAzXq9+T9W//2 ZT/WIN5WokZMPsiLg8/pvzPvTbDW X-Google-Smtp-Source: ANB0VdZpAm9LMAkWOf11pYPNc7R2nq9cMVvuLTrDwf7y6oFvhXZoB5XC5NtLq7L4TQuiZ/76+4InNA== X-Received: by 2002:adf:ad34:: with SMTP id p49-v6mr14764628wrc.10.1536569914964; Mon, 10 Sep 2018 01:58:34 -0700 (PDT) Received: from localhost (pr-audit.hu. [86.101.233.9]) by smtp.gmail.com with ESMTPSA id s131-v6sm17523332wmf.2.2018.09.10.01.58.34 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 10 Sep 2018 01:58:34 -0700 (PDT) Date: Mon, 10 Sep 2018 10:58:33 +0200 From: Tamas Szakaly To: freebsd-hackers@freebsd.org Subject: Attempting to receivce zero-length message with recvmsg Message-ID: <20180910085833.d4py4ladlyqchjvo@pamparam> Mail-Followup-To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: NeoMutt/20180716 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2018 08:58:37 -0000 Hi, I have a question about the recvmsg syscall. According to POSIX, unless O_NONBLOCK is set on the socket fd, recvmsg [1] should block until a message arrives. However, recvmsg returns immediately with 0, if we are trying to receive a 0-byte message from a SOCK_SEQPACKET AF_UNIX socket. Consider the following code: #include #include int main(int argc, char** argv) { int sock[2]; socketpair(AF_UNIX, SOCK_SEQPACKET, 0, sock); struct msghdr msghdr = {0}; int ret = recvmsg(sock[1], &msghdr, 0); printf("ret=%d, msghdr.msg_flags=0x%08x\n\n", ret, msghdr.msg_flags); } Running this yields this output: [0x00 socketstuff]$ cc socketpair.c -o socketpair && ./socketpair ret=0, msghdr.msg_flags=0x00000000 You can see that recvmsg returns with 0, even though there were no messages sent, and neither of the sockets are closed, so it should block indefinitely. Is this behavior intentional to match the semantics of read [2] (i.e. attempting to read zero bytes should be a no-op)? [1] recvmsg: http://pubs.opengroup.org/onlinepubs/9699919799/functions/recvmsg.html [2] read: http://pubs.opengroup.org/onlinepubs/9699919799/functions/read.html -- Tamas Szakaly @sghctoma From owner-freebsd-hackers@freebsd.org Mon Sep 10 15:28:36 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ED34A1093161 for ; Mon, 10 Sep 2018 15:28:35 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wr1-x444.google.com (mail-wr1-x444.google.com [IPv6:2a00:1450:4864:20::444]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6B55C868E1 for ; Mon, 10 Sep 2018 15:28:35 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wr1-x444.google.com with SMTP id s14-v6so13434318wrw.6 for ; Mon, 10 Sep 2018 08:28:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-transfer-encoding; bh=rjUzendxQLWHy27xHr+kw9T29nBdT/Lv6ddfFsLqpOs=; b=bqzL4DSJW4FMuhdx31Xm3nEQXmw4EQevWaiayol8KxGwzLsyXjkgnhONv3UJu4TDfq DcOBRJukJ5/FFUwdS2vwgABDukjyV9Y/QIL3AVz8MooO4I7oCxj5UqJwWlxllDf+hwPQ OLTuhAKeJAnqDrYg/GSdeOzK7N+DTj6loPAm5PmRIWaB3nDfyoBS5ZvCFriiLr3gkttS N5cXF5XPoAqqqFLKvyG5AXL8ExiGwThCh0NJbupgVC6TB6MNVlGWaS+VBX4gYQC93rNL FCssWK34Gw5Z9/54894Syx9UyL5MofUDIFkvhwmQCvrY1o6AkCq3Hky0I8QtYfnMvcP7 SFPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:reply-to:mime-version:content-transfer-encoding; bh=rjUzendxQLWHy27xHr+kw9T29nBdT/Lv6ddfFsLqpOs=; b=FcqqD0wUUbf5lKo25LXQFwy5eabdgfUEYCLhUZq9F0456S5P6JG2p32sdTVvcHx8Ib 8LPBhixEDxyirTDvt0nbybTd4tvwRYytTlmRGL0R/1vzG6Njef2vTKK18NIvQfjhiMHf iJlW5pgi8yqD6klZrobRkculul/Aas9WiexCgC7W++TUXdyV4JKCl1I0mak/Dir3fJxp U2GAAiCEhQs/x3jzz92IlvRo7p9gdDO+h9mGbFEJl+odYcfGbVkC/CpuoWjbfgfJMxod fxLVTyMO7Ie7lmG9DLmQTSWrdaVicFk9aYpuetrkv0Q4i2CFIU1FL9ezvK+qL74b5Z9h ki3w== X-Gm-Message-State: APzg51DgaeyEXcUeEu7A9qQiNQ2awWh8xNssQr4TiO3JP8R7qvLWAhaD XdibEtdVcpOUnPalZzo2KxZSB15f X-Google-Smtp-Source: ANB0VdYchwKeeLKCUoyw5d709yFdBVWLH5qmypJG2hWRoJ1Uvk90I07xR7UtTtATC466bQLO4qVeIA== X-Received: by 2002:adf:bd10:: with SMTP id j16-v6mr15170243wrh.267.1536593314384; Mon, 10 Sep 2018 08:28:34 -0700 (PDT) Received: from ernst.home (p5B3BE904.dip0.t-ipconnect.de. [91.59.233.4]) by smtp.gmail.com with ESMTPSA id t9-v6sm38920857wra.91.2018.09.10.08.28.32 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 10 Sep 2018 08:28:33 -0700 (PDT) Date: Mon, 10 Sep 2018 17:28:32 +0200 From: Gary Jennejohn To: Tamas Szakaly Cc: freebsd-hackers@freebsd.org Subject: Re: Attempting to receivce zero-length message with recvmsg Message-ID: <20180910172832.2c0a1357@ernst.home> In-Reply-To: <20180910085833.d4py4ladlyqchjvo@pamparam> References: <20180910085833.d4py4ladlyqchjvo@pamparam> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2018 15:28:36 -0000 On Mon, 10 Sep 2018 10:58:33 +0200 Tamas Szakaly wrote: > Hi, > > I have a question about the recvmsg syscall. According to POSIX, unless > O_NONBLOCK is set on the socket fd, recvmsg [1] should block until a message > arrives. However, recvmsg returns immediately with 0, if we are trying to > receive a 0-byte message from a SOCK_SEQPACKET AF_UNIX socket. Consider the > following code: > > #include > #include > > int main(int argc, char** argv) { > int sock[2]; > socketpair(AF_UNIX, SOCK_SEQPACKET, 0, sock); > > struct msghdr msghdr = {0}; > int ret = recvmsg(sock[1], &msghdr, 0); > > printf("ret=%d, msghdr.msg_flags=0x%08x\n\n", ret, msghdr.msg_flags); > } > > Running this yields this output: > > [0x00 socketstuff]$ cc socketpair.c -o socketpair && ./socketpair > ret=0, msghdr.msg_flags=0x00000000 > > You can see that recvmsg returns with 0, even though there were no messages > sent, and neither of the sockets are closed, so it should block indefinitely. > > Is this behavior intentional to match the semantics of read [2] (i.e. > attempting to read zero bytes should be a no-op)? > > > [1] recvmsg: http://pubs.opengroup.org/onlinepubs/9699919799/functions/recvmsg.html > [2] read: http://pubs.opengroup.org/onlinepubs/9699919799/functions/read.html > You have to initalize msghdr.msg_iov and msghde.iov_len, otherwise the kernel notices there is no place to put a received message and simply returns 0. I did that and recvmsg() did not return. -- Gary Jennejohn From owner-freebsd-hackers@freebsd.org Mon Sep 10 17:10:57 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 128511096438 for ; Mon, 10 Sep 2018 17:10:57 +0000 (UTC) (envelope-from sghctoma@gmail.com) Received: from mail-wr1-x441.google.com (mail-wr1-x441.google.com [IPv6:2a00:1450:4864:20::441]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 808AC8BF85 for ; Mon, 10 Sep 2018 17:10:56 +0000 (UTC) (envelope-from sghctoma@gmail.com) Received: by mail-wr1-x441.google.com with SMTP id w11-v6so22769267wrc.5 for ; Mon, 10 Sep 2018 10:10:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=BpXwXNWA6BqvkS8/2H8OIPrQ1JpXw2Sy0C2reey5QAw=; b=fdkZ81FTgeDiesDQnEH7nh0MVavNyyCH/NV5ZfH7/2KItdSczQQCAkNiTdMTF+tFy/ d4cJMrYiZ7odwRW+z5Gb5aSBd4X4ypKKNZDujhe6H1h+3We2iTF/f8UwuDhEjIgyPmHR iSe6FcogagKCi82a/KlY6vfi4Yd23RjWW6mV5LtsBQM4ctpwqm4U5VsbcvDTgI9PVyMB mnIGWrpKDsrOwzrE/6riqgKDHcgfOPUjZHg8WK+TYM++9zWhXOPSg0uDEA0LtISivpN+ AJXz5DOPEs0W1fW5No1rX26ztR8Pf2vg+Ob+Mo+8g2IHJdBMZHT62OfREB9zGlUvPHEL k5eQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mail-followup-to :references:mime-version:content-disposition:in-reply-to:user-agent; bh=BpXwXNWA6BqvkS8/2H8OIPrQ1JpXw2Sy0C2reey5QAw=; b=d5vYJkm21HltdL9jVXJ093WzrWqbcXpCq/fO8YP6N3gfrdQWfxpET0I/Kal/hmkUYv HvCGUf/vjmii2eMDw45WB1rf5Nzsf11BBDyPWOtpZcFBHrAR+gjw1YzZpVEKje9OLyEI oX/EDZm7+SwnZnrGUHVIJNWZBlYeTEPoAcVnXhnSIwlmdOpNOOQmPra53BmnwffaSC+V 9p8Hu5ZbeZeg6bQ+fsRnfp7P86i6Z4UfOhb/qAG1fTWKnvFQ13gEE41X1yPFnrry3BlB fuCrcuVGlW3JIpH1xAJYyHfc6Aud0FJ/99xpaiOakNs4Un8HqfMT8Lh07/ph51MAYmKU FIag== X-Gm-Message-State: APzg51BxcHBzwsYwvVR5Mqq/AKtNLShL1K8/xGN4XEzhv9bk+ev+vNss R0whMTMKfteK7MeuxQ/3whiKqhg8 X-Google-Smtp-Source: ANB0VdbqP/dYDbLIq640lK7CBNRZHSbE2I+/t+PjF+QkIOdwuW6ph9TripRmbGNzUqMaTXiAUK1/4A== X-Received: by 2002:adf:94c5:: with SMTP id 63-v6mr16665344wrr.247.1536599455112; Mon, 10 Sep 2018 10:10:55 -0700 (PDT) Received: from localhost (catv-176-63-26-157.catv.broadband.hu. [176.63.26.157]) by smtp.gmail.com with ESMTPSA id q200-v6sm15191770wmd.2.2018.09.10.10.10.53 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 10 Sep 2018 10:10:54 -0700 (PDT) Date: Mon, 10 Sep 2018 19:10:53 +0200 From: Tamas Szakaly To: freebsd-hackers@freebsd.org Subject: Re: Attempting to receivce zero-length message with recvmsg Message-ID: <20180910171053.3jvgw3i7fp6hetxe@pamparam> Mail-Followup-To: freebsd-hackers@freebsd.org References: <20180910085833.d4py4ladlyqchjvo@pamparam> <20180910172832.2c0a1357@ernst.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180910172832.2c0a1357@ernst.home> User-Agent: NeoMutt/20180716 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2018 17:10:57 -0000 On Mon, Sep 10, 2018 at 05:28:32PM +0200, Gary Jennejohn wrote: > On Mon, 10 Sep 2018 10:58:33 +0200 > Tamas Szakaly wrote: > > > Hi, > > > > I have a question about the recvmsg syscall. According to POSIX, unless > > O_NONBLOCK is set on the socket fd, recvmsg [1] should block until a message > > arrives. However, recvmsg returns immediately with 0, if we are trying to > > receive a 0-byte message from a SOCK_SEQPACKET AF_UNIX socket. Consider the > > following code: > > > > #include > > #include > > > > int main(int argc, char** argv) { > > int sock[2]; > > socketpair(AF_UNIX, SOCK_SEQPACKET, 0, sock); > > > > struct msghdr msghdr = {0}; > > int ret = recvmsg(sock[1], &msghdr, 0); > > > > printf("ret=%d, msghdr.msg_flags=0x%08x\n\n", ret, msghdr.msg_flags); > > } > > > > Running this yields this output: > > > > [0x00 socketstuff]$ cc socketpair.c -o socketpair && ./socketpair > > ret=0, msghdr.msg_flags=0x00000000 > > > > You can see that recvmsg returns with 0, even though there were no messages > > sent, and neither of the sockets are closed, so it should block indefinitely. > > > > Is this behavior intentional to match the semantics of read [2] (i.e. > > attempting to read zero bytes should be a no-op)? > > > > > > [1] recvmsg: http://pubs.opengroup.org/onlinepubs/9699919799/functions/recvmsg.html > > [2] read: http://pubs.opengroup.org/onlinepubs/9699919799/functions/read.html > > > > You have to initalize msghdr.msg_iov and msghde.iov_len, otherwise > the kernel notices there is no place to put a received message and > simply returns 0. > > I did that and recvmsg() did not return. > > -- > Gary Jennejohn > That's okay, but I want to receive exactly zero bytes. I can send such messages with sendmsg, and I would like to receive them. Of course I can introduce some dummy variable to initialize msg_iov and iov_len with, but it will never be used, and it just feels ugly. -- Tamas Szakaly @sghctoma From owner-freebsd-hackers@freebsd.org Mon Sep 10 18:44:56 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0DFD71098AD0 for ; Mon, 10 Sep 2018 18:44:56 +0000 (UTC) (envelope-from robert.ayrapetyan@gmail.com) Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8223E8F8ED for ; Mon, 10 Sep 2018 18:44:55 +0000 (UTC) (envelope-from robert.ayrapetyan@gmail.com) Received: by mail-pl1-x634.google.com with SMTP id s17-v6so10132812plp.7 for ; Mon, 10 Sep 2018 11:44:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=QDyyB3Q2CYE9I8zyhkaENEmegrinEdUBjYbomDIyQuw=; b=I30NIJyM3LHqCJBBbV7VF2mqzOUqKBFBb/1pnUn/MC2vjudbqNjJ20CJkkNR4GNwVw Viy+Ana45rohijzDn8aQIWFz5PZc33Pi02ZLDhZHKggx7UrLiu+vAi9uHNXGeAYDSoKc 2OjPmQYfzZGQPdfwDGCP6s351ZV99ujxvCEdRtxlxTiOUCujqhjcpZZ6UVOhtGR0TjwN ksyIsb9mAsTjroYOCsZxJtybBD44E+rjRMUCepegvBjBLhdZNLFpS3+VoMUcISVwNItb qG4MBWFhoLImUCPesE5PeuMMOq9r5uDxxp6xreoAjzipzzxw6HMT4Rjd2o6wEcs8G5mW IUOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=QDyyB3Q2CYE9I8zyhkaENEmegrinEdUBjYbomDIyQuw=; b=inwIDEsUZdXLCRPMOZHvC6zjmtsHqnJ/JNxzJHdEEi0uH7R5/zpgXamtFsVn1nlG07 qvkOHSUSBJKXRJZZ/yyqnYNoB8mxkzJgiB10xDPj+5eFvmL6BBGdq27jTMAKOtL8XZBn HWE2EtW6h8C7fCU4e8MSyz0oEbKjKrmuRLh/JELxxSWhAqMJg8vuuZeI215g5yIxMmHB 2uo63XvLy0E0TLqdQV/sRPUBTdmrVMoG8RQhB0DrwTXwC6r/tQQ3gsCX1zq8aay61J40 SZRq1AbwUT80Trcds4LT/+ZETLIYLDmlZ88xT8dAgc9pSJeevieQe1sGjNYl7ejQ0t+m e0cQ== X-Gm-Message-State: APzg51Cdl6ayCIwEW6Xcj46MJEBwaUJ0MkHpyN2U+9exBDj/CXRNo0zf Zfaf6nlycOwH08moZB0kY2kMywk= X-Google-Smtp-Source: ANB0VdaXmsuNzWKTGDG0sCF5JksknICBvSIfbbrDoXUgYi7uW2aP4kLWB8Ilg7bHbZxQh5AnLD1dtw== X-Received: by 2002:a17:902:6a4:: with SMTP id 33-v6mr8230536plh.226.1536605094184; Mon, 10 Sep 2018 11:44:54 -0700 (PDT) Received: from [192.168.1.113] (c-73-202-42-181.hsd1.ca.comcast.net. [73.202.42.181]) by smtp.gmail.com with ESMTPSA id d66-v6sm24602939pfd.121.2018.09.10.11.44.53 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Sep 2018 11:44:53 -0700 (PDT) To: freebsd-hackers@freebsd.org From: Robert Subject: Sudden grow of memory in "Laundry" state Message-ID: <55b0dd7d-19a3-b566-0602-762b783e8ff3@gmail.com> Date: Mon, 10 Sep 2018 11:44:52 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2018 18:44:56 -0000 Hi, I have a server with FreeBSD 11.2 and 48 Gigs of RAM where an app with extensive usage of shared memory (24GB allocation) is running. After some random amount of time (usually few days of running), there happens a sudden increase of "Laundry" memory grow (from zero to 24G in a few minutes). Then slowly it reduces. Are described symptoms normal and expected? I've never noticed anything like that on 11.1. Thanks. From owner-freebsd-hackers@freebsd.org Mon Sep 10 19:34:49 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D6CC31099D89 for ; Mon, 10 Sep 2018 19:34:48 +0000 (UTC) (envelope-from churchers@gmail.com) Received: from mail-ua1-x92a.google.com (mail-ua1-x92a.google.com [IPv6:2607:f8b0:4864:20::92a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6D12E718D6; Mon, 10 Sep 2018 19:34:48 +0000 (UTC) (envelope-from churchers@gmail.com) Received: by mail-ua1-x92a.google.com with SMTP id m26-v6so18445065uap.2; Mon, 10 Sep 2018 12:34:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4J4GeDU2lhMkipbVDOqmDOfaDcTGFD7p9Yfpt7EFFoM=; b=ObktK/hmaiPZhGkMOfc3jPxbZVnb+qwLL3sC6C+Gv0skhD5qoD+XlalrLP4FY6xX7o 6iq5n+HONpAG+C60wo1iXEVZlLwm5cxZnJUewv0OisjHRHOiimDjfOq7hmU0MRuhalW6 q138Wz8OdadGXofIuEReET4pjSaBydbJ0eJVZHQ0O2RZVQwvfWxJd4HM/EVV/tPghhoc s/O51Vy7bLax7D6DiCXMaDfcTspv6ibKbOSUW/mUdSAyWqA5aR1kmf87tcSeToAU6A3+ RC+4Rr42Rv4qka3nonb3GgF8VaotesTRHVBdGHuB2snIJE/o5uSc+nZKr0VSOFEYAGFp /k2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4J4GeDU2lhMkipbVDOqmDOfaDcTGFD7p9Yfpt7EFFoM=; b=kjlVaojtNHEUUvAKSZeFNJCUfBzLXGLmYqwQX+c1k2K958vhKND77abda3Zrbb93hq hXnMpV/Z7RcHgOZwcjgRlN+YAkLFPeIuYyhoLmEOK57IWDoAQf92hahAsw6gyA2q7esS b0hs6timuq9kAKnDFc4Sys/GgfzlcEAaGgyLEN7S57Hd8G30y0+PtOBRG3/3gVvBpGfx qQJXOZ7XJwfgLXUqewIrKRY6gnmL4YBmjNRph4b62uD5RVKK3e1+7DIaR1qu6xh8yisY WVuQTHCLsYfBTyqUMmN2oOyfg+J0vyI2lVB4au+yLF5nGu47XnHUfoDLW6bl7bhdwQsz 2c6A== X-Gm-Message-State: APzg51BNGoY6h7LdH9IMg463B1xNSpI/C/lL95vJssJIdEXrcj1cFHMh k0fWQFcQ+kJqxl4AbVS0V6fCYRMq5B8NazETvbFLsg== X-Google-Smtp-Source: ANB0VdZJSULVGiZ2j8KHI0JGP9ds2nlWcXk3XUOvnUpJfBavBC2m54lHjgDKzvXNsggRXB+zbjXtcfSOAmCGdoeSpj8= X-Received: by 2002:a67:e9d6:: with SMTP id q22-v6mr7249600vso.39.1536608087817; Mon, 10 Sep 2018 12:34:47 -0700 (PDT) MIME-Version: 1.0 References: <228b2a88-6134-c8c2-a28d-cb09cbc03ef6@freebsd.org> In-Reply-To: <228b2a88-6134-c8c2-a28d-cb09cbc03ef6@freebsd.org> From: Matt Churchyard Date: Mon, 10 Sep 2018 20:34:37 +0100 Message-ID: Subject: Re: Getting valid JSON output with xo(1) To: Stefan Esser Cc: freebsd-hackers@freebsd.org X-Mailman-Approved-At: Mon, 10 Sep 2018 19:57:53 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2018 19:34:49 -0000 Thanks Stefan For now I=E2=80=99ve altered my code to output the extra characters when ne= eded, and switch {} to [] using tr. I may raise an issue with the libxo guys and see what happens, as it seems to be a bit of a pain that I have to go through all this to generate a fairly simple JSON document. Matt On Sun, 9 Sep 2018 at 17:13, Stefan Esser wrote: > Am 09.09.18 um 16:10 schrieb Matt Churchyard: > > Hi Stefan, > > > > I did include the commands used to generate the sample output in my fir= st > > message. I am using the xo(1) utility, not libxo directly. I did mentio= n > > this might not be the right list (you've obviously assumed I'm directly > > using libxo), but it does seem to me this is more an issue with the xo > > utility, rather than just a usage error. > > Hi Matt, > > I'm sorry - you are of course right and there was everything required to > reproduce the effect in your previous mail ... > > > I've since looked further into the libxo documentation, and as you > suggest, > > it does seem that I need to be using the xo_open_list/xo_close_list > > functions to generate the right output. However, these are not exposed > via > > xo(1). The documentation for xo_open_list describes how it is used to > > create lists of individual entities, whereas the "l" modifier (which is > all > > I can access via xo(1)) creates "leaf lists", which are only for single > > values. As such, it seems there's a big hole in the functionality of > xo(1), > > meaning it can only really be used to create very simple JSON documents= . > > The following code fragment in libxo.c does suppress the terminating > new-line > character on purpose if depth !=3D 0: > > case XO_STYLE_JSON: > pre_nl =3D XOF_ISSET(xop, XOF_PRETTY) ? "\n" : ""; > ppn =3D (xop->xo_depth <=3D 1) ? "\n" : ""; > > xo_depth_change(xop, name, -1, -1, XSS_CLOSE_CONTAINER, 0); > rc =3D xo_printf(xop, "%s%*s}%s", pre_nl, xo_indent(xop), "", ppn= ); > xop->xo_stack[xop->xo_depth].xs_flags |=3D XSF_NOT_FIRST; > break; > > The reason appears to be, that closing the outer level construct will pri= nt > a new-line before other text. If you omit the second "xo --wrap", > everything > will look OK. And if you test with --depth 0, you'll see that the output = is > actually terminated with a new-line. > > > As I mentioned in my first message, it looks like xo(1) could do with > some > > way to open/close lists, similar to the --open/--close options, and a w= ay > > to specify that a single call should be output as a part of a list. > > I do not see a better solution than adding an "echo" command between call= s > to "xo --wrap", as you already mentioned as a work-around. This is simple= r > than adding list_open/close functions and it has the same effect, if you > know that you are emitting JSON. > > Best regards, STefan > From owner-freebsd-hackers@freebsd.org Tue Sep 11 00:54:16 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6C83010A092D for ; Tue, 11 Sep 2018 00:54:16 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DBA0B7CBF7 for ; Tue, 11 Sep 2018 00:54:15 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-pl1-x62d.google.com with SMTP id f6-v6so10528570plo.1 for ; Mon, 10 Sep 2018 17:54:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=2P/vSyopDGfOUHpI+dBHqU/jFEWx/800JWmHhq2s+fk=; b=MSdh+zqiXDCCuAyHVHV42OBBvGWFToCGmIEwigcZ9cwrF0sAwJNQPO7c39g8+me8Nf Ew8ib6MK95WkeKtELTPpLf3twhOs1s0eH1KxCcAgu+z7ON2mF5woM3ZTm6k0BSNyYH6n a9xajE9dBUdZ4DIZDMpu98Qe6KhEYY9DXv52IsJoGXQ4y5m8ubkP4s6paV9CejZLRg4u ZvBq2e8yPdDCQBs7oTqj5zhBPzD+Y/OOyYPX8z8zwwurrIve2kqQZHBFYXSfFJ6Qvnxt QP+dy47GsHiOAbcD/XBG0J3abzgJUoKn5V6/8r4120/YKvJjamswY4vS6ifS2Zld5Hun 9Dtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=2P/vSyopDGfOUHpI+dBHqU/jFEWx/800JWmHhq2s+fk=; b=HoUaCnG53rNDcRX4TzN1W90aByrHFAsdbVvMBHvcvmLFNSbaLiLGGG/5+JiCsaGaLo Ji0bX3nGM6JI/ZwfbdMaY43FDxxtJtcPyqeVDHc3StkUXIrGz1v2ufb1pcP1zcunYWVa Zb54RvwWcXsSwCPriAwtE+MVJLS8XsDpJxKIBh8b5bCTKaCYxZV1b5v3XMXgDghP3sFV 1wrbM5fZW9m9NxtuYpr0kCDqUW1u0DXTf71FttjYbHHQ93NxIIUa13MQz6iPHJT/Semm AKC+ilHJ5ddJeCGjMHTHhMYy4WvGmkcl4nqSKCwGlYsQyOJSLiqSdK2sl+z5Efuczmch sYQA== X-Gm-Message-State: APzg51DV0V6tazlc82hnTihb+FQL3GmNzEo2iC6zCOPktMk08lC0RAop X7ulJI+yWbLlFMOAvqzokhr9KGgw X-Google-Smtp-Source: ANB0VdY5EdaJ+Dc/wRVheoeT0iXaDn+m8FO+dhLYEdjc+3QA7gh3VC4Gkg3Y5keXAttthsmzGQxnNQ== X-Received: by 2002:a17:902:8d8c:: with SMTP id v12-v6mr24137876plo.94.1536627254867; Mon, 10 Sep 2018 17:54:14 -0700 (PDT) Received: from raichu (toroon0560w-lp130-01-174-88-78-8.dsl.bell.ca. [174.88.78.8]) by smtp.gmail.com with ESMTPSA id z8-v6sm20956070pfe.163.2018.09.10.17.54.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Sep 2018 17:54:13 -0700 (PDT) Sender: Mark Johnston Date: Mon, 10 Sep 2018 20:54:11 -0400 From: Mark Johnston To: Robert Cc: freebsd-hackers@freebsd.org Subject: Re: Sudden grow of memory in "Laundry" state Message-ID: <20180911005411.GF2849@raichu> References: <55b0dd7d-19a3-b566-0602-762b783e8ff3@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55b0dd7d-19a3-b566-0602-762b783e8ff3@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2018 00:54:16 -0000 On Mon, Sep 10, 2018 at 11:44:52AM -0700, Robert wrote: > Hi, I have a server with FreeBSD 11.2 and 48 Gigs of RAM where an app > with extensive usage of shared memory (24GB allocation) is running. > > After some random amount of time (usually few days of running), there > happens a sudden increase of "Laundry" memory grow (from zero to 24G in > a few minutes). > > Then slowly it reduces. > > Are described symptoms normal and expected? I've never noticed anything > like that on 11.1. The laundry queue contains dirty inactive pages, which need to be written back to the swap device or a filesystem before they can be reused. When the system is short for free pages, it will scan the inactive queue looking for clean pages, which can be freed cheaply. Dirty pages are moved to the laundry queue. My guess is that the system was running without a page shortage for a long time, and suddenly experienced some memory pressure. This caused lots of pages to move from the inactive queue to the laundry queue. Demand for free pages will then cause pages in the laundry queue to be written back and freed, or requeued if the page was referenced after being placed in the laundry queue. "vmstat -s" and "sysctl vm.stats" output might make things more clear. All this is to say that there's nothing particularly abnormal about what you're observing, though it's not clear what effects this behaviour has on your workload, if any. I can't think of any direct reason this would happen on 11.2 but not 11.1. From owner-freebsd-hackers@freebsd.org Tue Sep 11 01:28:42 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 679EC10A2D37 for ; Tue, 11 Sep 2018 01:28:42 +0000 (UTC) (envelope-from phil@juniper.net) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.pphosted.com", Issuer "Thawte RSA CA 2018" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BF7507E48D for ; Tue, 11 Sep 2018 01:28:41 +0000 (UTC) (envelope-from phil@juniper.net) Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w8B1Nd1M004840; Mon, 10 Sep 2018 18:28:40 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=message-id : from : to : cc : subject : in-reply-to : mime-version : content-type : content-id : content-transfer-encoding : date; s=PPS1017; bh=NmS+fYD93RhHwo9U8fGEQBVz8Efi/8ysjfXCx11brdg=; b=gkUsFUK4bIdcgWLlmfaZ7BtwWfUB4LAIAuGTUT+M+xT07t/UxxuPGPbo9UHuNGw8Us0f Ai+6QR+t+S/X1Tt4qP/kROo33R7IU8cw9rJszArdqLDgnX57WUCeFzOVEIa+EuQQasDo 4y9k/oPJQTKuuh6DfRIv5DGxSuXJtDJMr16sqkxL7TJ4+ltLwHD7vUkRqYuzhNSRrlm8 GDx4go+bDG703BNjECeN8Gd/Jibyp5Qb6qk6yQ78XTMAOrXO01nn0GJRp3PjC0Yo7Ls3 +UpWuXO0uhut45uPBRu+gCwDR25zE7HhY9jcVGAwrSG+bCD1Zq9s7DaGYQ57dPBG1jRY Ew== Received: from nam01-by2-obe.outbound.protection.outlook.com (mail-by2nam01lp0180.outbound.protection.outlook.com [216.32.181.180]) by mx0a-00273201.pphosted.com with ESMTP id 2mdssms3ud-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 10 Sep 2018 18:28:40 -0700 Received: from BN3PR05CA0010.namprd05.prod.outlook.com (2603:10b6:400::20) by MWHPR05MB3119.namprd05.prod.outlook.com (2603:10b6:300:b2::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1143.9; Tue, 11 Sep 2018 01:28:38 +0000 Received: from DM3NAM05FT013.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e51::204) by BN3PR05CA0010.outlook.office365.com (2603:10b6:400::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1143.6 via Frontend Transport; Tue, 11 Sep 2018 01:28:37 +0000 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.13 as permitted sender) Received: from P-EXFEND-EQX-02.jnpr.net (66.129.239.13) by DM3NAM05FT013.mail.protection.outlook.com (10.152.98.122) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.20.1164.5 via Frontend Transport; Tue, 11 Sep 2018 01:28:37 +0000 Received: from P-EXFEND-EQX-02.jnpr.net (10.104.8.55) by P-EXFEND-EQX-02.jnpr.net (10.104.8.55) with Microsoft SMTP Server (TLS) id 15.0.847.32; Mon, 10 Sep 2018 18:28:24 -0700 Received: from P-EMFE01C-SAC.jnpr.net (172.24.192.43) by P-EXFEND-EQX-02.jnpr.net (10.104.8.55) with Microsoft SMTP Server (TLS) id 15.0.847.32 via Frontend Transport; Mon, 10 Sep 2018 18:28:24 -0700 Received: from p-mailhub01.juniper.net (10.47.226.20) by P-EMFE01C-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 10 Sep 2018 18:28:24 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id w8B1SMSq027487; Mon, 10 Sep 2018 18:28:23 -0700 (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.15.2/8.15.2) with ESMTP id w8B1TG1Z022255; Mon, 10 Sep 2018 21:29:16 -0400 (EDT) (envelope-from phil@juniper.net) Message-ID: <201809110129.w8B1TG1Z022255@idle.juniper.net> From: Phil Shafer To: Matt Churchyard CC: , Simon Gerraty Subject: Re: Getting valid JSON output with xo(1) In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <22253.1536629356.1@idle.juniper.net> Content-Transfer-Encoding: quoted-printable Date: Mon, 10 Sep 2018 21:29:16 -0400 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.13; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(136003)(396003)(376002)(346002)(39860400002)(2980300002)(199004)(189003)(69596002)(8746002)(2810700001)(1411001)(336012)(4326008)(26005)(5660300001)(76506005)(77096007)(81156014)(53416004)(126002)(316002)(186003)(107886003)(54906003)(14444005)(6246003)(8936002)(6346003)(229853002)(6306002)(46406003)(39060400002)(68736007)(476003)(81166006)(7126003)(11346002)(2906002)(7696005)(486006)(106466001)(426003)(105596002)(53936002)(86362001)(50466002)(8276002)(23726003)(478600001)(1076002)(47776003)(97736004)(305945005)(97756001)(356003)(966005)(8676002)(6916009); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR05MB3119; H:P-EXFEND-EQX-02.jnpr.net; FPR:; SPF:SoftFail; LANG:en; PTR:InfoDomainNonexistent; A:1; MX:1; X-Microsoft-Exchange-Diagnostics: 1; DM3NAM05FT013; 1:yQFDFoigjQEeh4MT8T1rTXy9Uhnyh6zB7kndgMJJaOX6eLRcNV8MmlhLEPc/N03njuDYW0SjZX7PaYL4qk8cLvkDt3LAp1n1pvvzo8ix2myQOHB7m1cWRPrf5dykpdKY X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 2f7c3db4-e962-4ad0-6668-08d61785e60e X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(4534165)(4627221)(201703031133081)(201702281549075)(5600074)(711020)(2017052603328)(7153060); SRVR:MWHPR05MB3119; X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB3119; 3:0pk6rS0Td4HCl8C6W90TnAyNrXUzWO9vLlXUDwMvJ/Pz3LU5zpMmAXDbwu/9F1wmpy8Hrxx+KbPBu1W1ETPkPgYVU51gfc7SRlWaLz0HiDicfb+yHGnHgC0ujrlYcfhxy8/w2MMBd7tA3tPOUPVmA0S2vFFaSS2qKXeoHyhtbL3u5GLXDYLb+flN7ZvHTF/n/EJUl59K7pcxOu/CmrC7iQgK3VDNUFz8sussHLdwcJz6W9P1g5e3+OkKlAr82tEkEcwuqhCK2sNdwKd+/bYjo80bZi6g5fCpw4yPghNI3Q0yv9rGAt+ckMgK7bgRoGRQ4iA6s9/be2BQSGEBQZ7KwkCfHBd5UTuAgeouP4Rj/RQ=; 25:G39y5JNIuINDrksc+64pQKXlTLNFpFIKAbZp1MpooFClVVMoSsZFuvZZXR9ZVhjUekhk94lpVAsalTA5qjdVeKO4IduMp2MqEO+irtp9CCpY1/YcrTYwnPsO4tla/YzoHCGZDqwxoagXppFw2RLBx2XleA0fT3LcIRF1PaDG1+PZiJflCG5RMb60k8ArFSdoQ1iEUhuvM3n6Z9VwQ3xM0bggEuBWNJO+rZcOGfZEAV0AhgHwD5H2muv01fhUGD/Ms+QEm8xeRDERAvvwQB63Ia1WXlZ0+hDc72KnwJeGhtMR5kmi2JFfxDWubC3Q7n7f9mqfnxryhWEvfwtJwCzZeg== X-MS-TrafficTypeDiagnostic: MWHPR05MB3119: X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB3119; 31:C/baea9U6Wba0XukUkAKLA6YkGS5Aga2qqadEwsgFosmBg+fLcUsUfw4YNxihZPT3KDAQSzHuMuOcSRUm8Euzr1D/ymc3cV86RBv6ojnLjoQgfy4u1dWvBN1N9h79NHvjQ/2dYjUmj36UTet6yT3yaOlGapaSfWxFHgxzEcFz6v44Iaw6ePbovLEO6XDlCC1ovXImMZbR9Wpo5w2VLgwdqy/EmW66uiPaPbb7HcW5aM=; 20:Af+8mzs40HtJSqvsMgOAiourwq2/pzmMzZPekeJxPNbA6wKOaMRz08br6nzBqb80qeI0dX8qvTkZYD15d9Utq7+drnCJggbTNjG31Ley+Ehf4ZJmnvr4M28XiegF44BY5/UGNPzBilyD1FpTecYh322C4e7Ad2HMcidVnYRo7tYX6udqnqdYslL4DQXX9JvwqckRnp47VGudjhoMkeJmV61GU8hN8/yI3yJs16hxQwKzLhCtt3ffFi4wJeMuHH0Yrxu9vZBG7Lc5oNvbujExqsZysShDeqDsMuYt3y/8ZEij07hfMhftCmJ5bELEDfOMzBVLouh5znqIfRMGpMysxlJ8+EWGE8O14jDJuQu2/v8nMPbcoFHmSb6WRFeWgc0iUrFV5pbnuiQETa59H7s/68p59CkUfHeIWxrSL/06eFLM2+ZI1GYayd0MGB3xEWpMC28W5GNDCZguJShJ1v49G748T7r9aozptwgTke0cj90rzF81uIsPlH95/9SqCacS X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(166708455590820)(17755550239193); X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3002001)(93006095)(93003095)(10201501046)(3231344)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123560045)(20161123558120)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699050)(76991033); SRVR:MWHPR05MB3119; BCL:0; PCL:0; RULEID:; SRVR:MWHPR05MB3119; X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB3119; 4:rQI1x2uPJor17m0ARI8h99tmsG8OSjO2yKuuAQINXwHrI1XbeutyV4Sa10ocCDIvMxiMF3btEq56yEqxCPSB7zK0Nx0ERXsUlOEikJg9r7iSE8A9iQsbsCb7z3Na4j1K8LNnPPQ2pr2UpPSYoTCdjboA0kVmEK7fHplHbXCWqyJkB7vXIc3vu9r8CtPbDAFw81AT6xb2Hdk8BWDWZykj+nmZ19tVlin0RWAy9tIl2GrXJD8Yv0rfcDyCDsXktsewSHzteJzekQ/xsLhqI1h/+ROYhyZaT//H9uD8uzJ7+dPFWI36U724ojd/RGD/t8C24NYelBr9fa8BmvdhqhbYQXsuWgcA1D0N8H0JvcDhDQw= X-Forefront-PRVS: 0792DBEAD0 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; MWHPR05MB3119; 23:DUbi5+uo6HLpMgZtbtVRm/aqV6cYjIogUpUov1pL6?= =?us-ascii?Q?8gTPYz4qJGZRID7LSGmc5O7Vd3ybS0Ok3AWHPSEa2RONwXSdKpUjqEIaHykt?= =?us-ascii?Q?Ql3MJ+eJCtQFSM+JBU69Ap0Etov7VWWIpvTSTN3nVcrH/H6ghI3LCTawSRqn?= =?us-ascii?Q?7P7LuHMaqWmyNCGt1cxwe7mgBAo3vH12o3mc7PWaL8+KG7qhI/isYuXfQw40?= =?us-ascii?Q?fzLC+mMAd0J4Gu64QwyNLaCb6GcokK/d6ONIYBMYQgwiPokvb8nrbkwe3Mww?= =?us-ascii?Q?/uCUf8BcICYa1Jr+uEG5gv7jBu0mLqEo8xQAsBfND76T+Jim+cGU6yaT5iqp?= =?us-ascii?Q?99WYXWgoACfbRCW+PS4MPg7B5WlivbSoe84nknRLJZsQbhK6ywC37M8YDQaQ?= =?us-ascii?Q?64nDZWVV2cP0hgwX7E6EkL6GH/RfAifJDhc3MMYZwra09MMA/9iyWXeue2MA?= =?us-ascii?Q?d7qwqTug4ursvBoWehPK31ZNmR9BkT7sx40n3nR1C0dKmIdqXvR25dgbupRx?= =?us-ascii?Q?c02xQyslWg03MTliM7DOJJgvSG1qfaHHINKYLFXFcZUtmay3xMvryGttwJ4F?= =?us-ascii?Q?ZT9FK6awlJyv0V+/tWEmhLVYtlRGbYalZY3cRkr9lT2QkTUhr5ki4rtm55m8?= =?us-ascii?Q?VPB23KP4GfL8S0r7P/dQl/B0ljPbTxO17CYPA7wPmxxIsCd+geM4G5H5zdPE?= =?us-ascii?Q?gnZazHpHssyIBcXr0soR//MGNYaEyGm43LGAlEsD791DXu8wsvmcAn0e60aT?= =?us-ascii?Q?RfQUR5EFs+Ttn+r8387l8FqeXn5ZtrSJJVeomTsvdRiNY1D5ObfG0wLDu6ty?= =?us-ascii?Q?KoAA66VcRLaKp9/UCzXoZd4891Lz1KARsH8YUp/zFncJHKWOboxINOMDkUG5?= =?us-ascii?Q?BDE5hx8eexhZIr57lZxg+RiEic7/e0+AEOJIuqI/I2BSxYusx8EgzULROYit?= =?us-ascii?Q?8/EqWXy9J1Uue+5j4YiVVya/6lWCAtVx4SbOMcc+Yp3x5ewWBgprTyn0pWfQ?= =?us-ascii?Q?yIYK0kKMZwDq8xK8FFcKjuJDeY4I+EypoyOx+CZaJ1W1UUlzQ3ER/Nz8fi5U?= =?us-ascii?Q?PXadK5s2RdTtFXfu8/dTHod9R2W08yBf52sRdj4tFZ2+6lQledMFqqnUjZaK?= =?us-ascii?Q?03TqGNQnnlCgMM1S5OOMHo20EvGcRg6iM3arZguiu8J1rbzENR4WjnEfPfAv?= =?us-ascii?Q?EQMbG82V7KP+TpaQEwhUNZrV5h1t1WrgWUmBfYcPezFzoLng4oHXbJvseLNH?= =?us-ascii?Q?iGtQdTmf+Mj3ywr8uIvS9vyMTwpwOoUuKHZ6Y90qw59hRe8014q9kd0nBG2Q?= =?us-ascii?B?UT09?= X-Microsoft-Antispam-Message-Info: Bf0+57SmLX4PGlBZNuZQWaTWblYpjjhrShsJ6QKIt7sApxdZUdZ77KcUxW2wCUmK1NTFxn2QR0sWTsZNPi6KoaCtxGKTPc/+Rt1Z1UUrp2zsk9VB5fwdShHwMVVEf94wLMQZ+5OMGFf50V3Hz8B2Q/Jg1PKq/y2KNWuHVy4/yArgPAAhg5OghDD1+3E1imaZceVykd1FXplb+oFD9AMsVchsyuxEwvW5VzJKaMqBDtacdnvX88s4qEja5qG4S4PZPh9w+wnJbfgE3g9o2e88m61d2wosIhUHlbRlKTFg89GYLZqIxGkCBnw+Rd11Y1UO50QH3yNSYf0IdbY8MdDeyYo2jKJwVR0roTSk6lxLhYo= X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB3119; 6:rvv1ScwQ3V7JzDtToAaV/uSk6JRSSRDe6GV+IfpiU4xclIRTYclG6ZMP8yl99ArSmycbgHO8WUjMbQGwcRmIP1S8ujA4tr00AQVrEbKjGAyCgpkwJVqM/flOYYzaZdmdluh0oyT+T/QD0zhtY1ZKlETo5PoO1bP3niVagw7JZvCar1JXWR4xdH3bib4QYMyPBRBSzNFYRYP6pumzNzrG/PKyyIq61uTzXntrqejdcQ4mGdONZbUy7t2ogy4T9Ml4PWj371/BdMOgLi/dS5OoIxwoHtT7HPKRp6QERVh4Z2hktq1b+Bnokj13a3/oA/WZxcWcGoSeMLrUaCxLnhx5cwHlHRhSW8jWQ23ioPvWie6IB1IAs7baeujH8ALgBES3X1tSG8oQM8zRDn+L7bqI3OFBPkAj7uP8W6BfiCtvzedKzTlvQOarXndiy6kwVa+SFVBbmzJg3L2M/JgXluMKNA==; 5:/OfXhyN/BX4Jzg4avLnRCSn8pPPEMoG4gBG3vLiZI1GnWwO82QW1UylDp6YxR8qzzmC9U4McFGLHECnwKWt7Hrwm8fEH8lni6QQV+1+gOPJjrnkyPOyzslQos5GN6yAfmIf9z5p4LqQjC3PrCV/btNUMHSrK1maZbRFCuT1+GS0=; 7:/4yhtg0qiYhmGq4Aa+rjdAQj+jW2H/8G+RV80OKZf41M6OrjbjMhg8a3kPrFvmCzyv2Ltiy5lyZEheRVBF/hZuPUQcROQ6IQFUZMeJgH/D3jOZEv3NwYQPQvg3JSkEUTBNr0LiV6yzf02IB9Cvb7u1KnWlBWTjedbErpyse6+55+S+PwfrUwddHUJ8VsxEKcs7bqABF76TcP1JT0xBSZJa7DmeBQp/85nC8HiTWhWrwRwe/O9D2SfSaVnoIQnv3G SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Sep 2018 01:28:37.6046 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 2f7c3db4-e962-4ad0-6668-08d61785e60e X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.13]; Helo=[P-EXFEND-EQX-02.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR05MB3119 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-09-10_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=1 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1809110014 X-Mailman-Approved-At: Tue, 11 Sep 2018 01:45:13 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2018 01:28:42 -0000 Matt Churchyard writes: >Sorry if this is the wrong list, I wasn't sure which was the most >appropriate. Best path for xo-related bugs is https://github.com/Juniper/libxo/issues Email directly to phil@ is also reasonable. >If I choose HTML output I get the following invalid output which is missi= ng >closing
tags. > >
>
test1
>
,
>
2GB
>
>
test2
>
,
>
4GB
> >This can be fixed by adding "\n" to the end of the format lines, which ma= y >be required, but it seems strange that I can so easily generate broken >output. Yes, without a trailing newline, libxo can't declare the output line "over", so it doesn't make the
. The problem is that there's no mechanism to "xo" that your output line is continued from the previous one, and since "xo" is stateless, it will happily start the next chunk of output with a new open div. I'll add a "--continuation" option. (#58) >"bhyve": { > "machines": { > "machine": { > "name": "test1", > "memory": "2GB" > } "machine": { > "name": "test2", > "memory": "4GB" > } > } >} There's an "xo" option called "--not-first" for exactly these situations; place that option on the second invocation so it will know to emit the leading comma. This should be documented (#59). >1) The entire document needs to be inside braces "{}" so that "bhyve" is = a >member of an object. "xo" doesn't currently do this, since it assume you're generating JSON piecemeal and have a better idea that it of what you want to do with the output, but I've opened issue #60 for adding a "--object-wrapper" option that will perform this. >2) There's a missing comma between the two machine entries The "--not-first" option will repair this. >3) "machines" is an object, which erroneously contains 2 "machine" keys This is a bug. "xo" lacks a means of knowing that an object is a list. One might expect that labeling "name as a key would perform this, but it doesn't, and it's not clear that this is enough information. Since "xo" is stateless, it cannot really handle that "--wrapper machine" applies only to the first item. It would have to know not to generate the closing "}" for machine, but it's stateless, so I'd need a means of telling it that. In C code, we have "xo_open_list" and "xo_open_instance", like: https://libxo.readthedocs.io/en/latest/api.html?highlight=3Dxo_open_instan= ce#lists-and-instances But with "xo" I don't have lists and instances. I'll need to find a means of adding these, though that would make "xo" more cumbersome and it would lack the FSM (and the stack) that catches missing calls in libxo. xo $opts --open-list machine for name in red green blue; do xo $opts --open-instance machine xo $opts "Machine {k:name} has {:memory}\n" $name `get-mem ~name` xo $opts --close-instance machine done xo $opts --close-list machine Which is very exact but less that beautiful. This is #61. Thanks, Phil From owner-freebsd-hackers@freebsd.org Tue Sep 11 05:18:36 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 50F6410A944B for ; Tue, 11 Sep 2018 05:18:36 +0000 (UTC) (envelope-from robert.ayrapetyan@gmail.com) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AA85D859ED; Tue, 11 Sep 2018 05:18:35 +0000 (UTC) (envelope-from robert.ayrapetyan@gmail.com) Received: by mail-pg1-x532.google.com with SMTP id l63-v6so11619178pga.7; Mon, 10 Sep 2018 22:18:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=t3Xh3BJs5LdScuZ2vp5XUQ612zqUQ7Xt0BblZRt9Sh4=; b=DJ5rSgZNJSEC1JLadFHdLYtiGruDvaHm2ou/haPK2ZvUDxtqeWZDGQ+XWGKuso+Wze fKz1TkmAkfE642cZCyPBwqUO4AL8WGYhTYDxo/wZNi+H45UKksFcv7+lOsXq2kp08HCu ZjrZ3KK8e0p6/Li0myoKapmSTJLS+NFyrKFqGqDNfV6t3QLSdYbS4Tazwo/UV5U1VPss 4LTl8QK6uBNZzqem0GmHoOdjyRyfwUwjfMm5eyldz0ENdm7h8BMWg9ojCyctZX0Zs0GS IhOrPqOqXdiBWf2Lcsx9L1PXzRzpnRA3PYaxe+C5q3xlLEG0/mn1r4N0cbOahLitn2P8 FWjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=t3Xh3BJs5LdScuZ2vp5XUQ612zqUQ7Xt0BblZRt9Sh4=; b=g5gNsv3AH0AZ9aTsc7BBRpTjC0EajeVPMUA/Mmf2ucV8uwk6Tu38Hpo3GR/OiM/oLI h6fArNsUXLIeunuw7DCrrHGH4ZkkOvbzDm34raeAaDezV9uKnEPwGzwMPN/JaNLF7Ux5 4WgxUOPuQrwXXCh4OIUq20nov1XEt+gRHyogUj/GWtWO4WmvBr2wyBl4rNCHqQDSoJoT Rz/071qVOznF27zOJkApExyA3e8/XNWdxcPpnB8DVpRgM7P1gyBDxp1vxa72ys66TgNb HUvqnxoRr4/EmkjW9NktImgEU7WLdrWZ+Ezbohj5kLSg/Sn0DHn0oN8syUALTuEbCqVI tYqA== X-Gm-Message-State: APzg51CT1+v+qWSIz1nJsA6IXGTD0veC/l/ZtPdJByhOHaVRrJsDRhnE xUGC8nktwTcZK7ZmDA4K4zdZxGkvwg== X-Google-Smtp-Source: ANB0VdbLqIwGyuwdFK714F1LZ4SuqQXPsD/6XpEqc8pCuk/SLSc9clLqI/qGWpRgI2SWDjR1BXl6uw== X-Received: by 2002:a63:4702:: with SMTP id u2-v6mr25537973pga.95.1536643114178; Mon, 10 Sep 2018 22:18:34 -0700 (PDT) Received: from [192.168.1.113] (c-73-202-42-181.hsd1.ca.comcast.net. [73.202.42.181]) by smtp.gmail.com with ESMTPSA id v2-v6sm24078082pgf.58.2018.09.10.22.18.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Sep 2018 22:18:33 -0700 (PDT) Subject: Re: Sudden grow of memory in "Laundry" state To: Mark Johnston Cc: freebsd-hackers@freebsd.org References: <55b0dd7d-19a3-b566-0602-762b783e8ff3@gmail.com> <20180911005411.GF2849@raichu> From: Robert Message-ID: Date: Mon, 10 Sep 2018 22:18:31 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20180911005411.GF2849@raichu> Content-Language: en-US Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2018 05:18:36 -0000 Hi, if I understood correctly, "written back to swap device" means they come from swap at some point, but it's not the case (see attached graph). Swap was 16GB, and slightly reduced when pages rapidly started to move from free (or "Inactive"?) into "Laundry" queue. Here is vmstat output: vmstat -s 821885826 cpu context switches 3668809349 device interrupts 470487370 software interrupts 589970984 traps 3010410552 system calls        25 kernel threads created    378438  fork() calls     21904 vfork() calls         0 rfork() calls      1762 swap pager pageins      6367 swap pager pages paged in     61678 swap pager pageouts   1682860 swap pager pages paged out      1782 vnode pager pageins     16016 vnode pager pages paged in         0 vnode pager pageouts         0 vnode pager pages paged out         3 page daemon wakeups 1535368624 pages examined by the page daemon        12 clean page reclamation shortfalls   2621520 pages reactivated by the page daemon  18865126 copy-on-write faults      5910 copy-on-write optimized faults  36063024 zero fill pages zeroed     21137 zero fill pages prezeroed     12149 intransit blocking page faults 704496861 total VM faults taken      3164 page faults requiring I/O         0 pages affected by kernel thread creation  15318548 pages affected by  fork()    738228 pages affected by vfork()         0 pages affected by rfork()  61175662 pages freed   1936826 pages freed by daemon  24420300 pages freed by exiting processes   3164850 pages active   2203028 pages inactive   6196772 pages in the laundry queue    555637 pages wired down    102762 pages free      4096 bytes per page 2493686705 total name lookups           cache hits (99% pos + 0% neg) system 0% per-directory           deletions 0%, falsehits 0%, toolong 0% What do you think? How pages could be moved into "Laundry" without being in Swap? Thanks. On 09/10/18 17:54, Mark Johnston wrote: > On Mon, Sep 10, 2018 at 11:44:52AM -0700, Robert wrote: >> Hi, I have a server with FreeBSD 11.2 and 48 Gigs of RAM where an app >> with extensive usage of shared memory (24GB allocation) is running. >> >> After some random amount of time (usually few days of running), there >> happens a sudden increase of "Laundry" memory grow (from zero to 24G in >> a few minutes). >> >> Then slowly it reduces. >> >> Are described symptoms normal and expected? I've never noticed anything >> like that on 11.1. > The laundry queue contains dirty inactive pages, which need to be > written back to the swap device or a filesystem before they can be > reused. When the system is short for free pages, it will scan the > inactive queue looking for clean pages, which can be freed cheaply. > Dirty pages are moved to the laundry queue. My guess is that the > system was running without a page shortage for a long time, and > suddenly experienced some memory pressure. This caused lots of > pages to move from the inactive queue to the laundry queue. Demand > for free pages will then cause pages in the laundry queue to be > written back and freed, or requeued if the page was referenced after > being placed in the laundry queue. "vmstat -s" and "sysctl vm.stats" > output might make things more clear. > > All this is to say that there's nothing particularly abnormal about what > you're observing, though it's not clear what effects this behaviour has > on your workload, if any. I can't think of any direct reason this would > happen on 11.2 but not 11.1. From owner-freebsd-hackers@freebsd.org Tue Sep 11 05:19:37 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7419B10A94B3 for ; Tue, 11 Sep 2018 05:19:37 +0000 (UTC) (envelope-from yuripv@yuripv.net) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (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 1304085AA0 for ; Tue, 11 Sep 2018 05:19:36 +0000 (UTC) (envelope-from yuripv@yuripv.net) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 26341620 for ; Tue, 11 Sep 2018 01:19:29 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Tue, 11 Sep 2018 01:19:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yuripv.net; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=77spYVK6iicScPy3G494ohXqhZvKvINxMyOX+q1NDRs=; b=f6HrRhUX NRMtnA+hBEpmBUgs8B8Npyd3ekirwHCUDFdd7dLQoMeMlgn0o39oA94aKyCiobu0 vAETxYR9XOuXGjWOuBdricF7S/9R0lzzoi4RZ+oHEQkzrjmZx7aHadj5az3hW4sG 73owc3QjoxqLxsMOt0pkudr3e9mIEbHQKk0KrH1OMaDUxcZj8RD+g8kCyWw4r8nm jNgo217MpswIz/MvPaF0e2EhXhOAYAjPFOu835YEyakDCC6qdjIho5v4ug9YZfZE pkWRo6ZO7Ap13MUB8dyAcVpFs2mtWy9dC+lJwJJp6hxJCWV0wl8XzerrHXkfNHyd 4DdTz/5jpJtajQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=77spYVK6iicScPy3G494ohXqhZvKv INxMyOX+q1NDRs=; b=X47FErYzZ1cgL7WzuI8EFyMt21G5lK/x32eqiriE0USA+ AqCaUo9bPH0wYyuxFCXEQmSXWuDRF2I/SBPFz2tn/woftSg1BpwsBrT/gvAnnYVe o82aQdLd2c/15ucEFrejwCVlWp/JqGud0EPX6pu1BkMp6bx82Gj/gWcgXrlk9DrH nO8wq1rmnI44VCqIYRDGbvvybIc+PhePR6zTQ34s0JUQ9+6fJvv/ndVdJcMbBfxW f42IW8Uv0jdxubPHEBjilvnVV/2WLo47HYhKe/tVmx8HUxF339Tw68WfSuDW/dIh SAEJrVHDup0D9p7un3cfchDNAyJ+wd/Nn3Pzj30sw== X-ME-Proxy: X-ME-Sender: Received: from [192.168.1.2] (unknown [178.34.113.240]) by mail.messagingengine.com (Postfix) with ESMTPA id 6D615E4041 for ; Tue, 11 Sep 2018 01:19:27 -0400 (EDT) To: freebsd-hackers From: Yuri Pankov Subject: ACPI GPE handler: mtx_lock() by idle thread Message-ID: <475afc8c-d0ad-ead2-e75e-bca873977c2d@yuripv.net> Date: Tue, 11 Sep 2018 08:19:26 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2018 05:19:37 -0000 I have the panic shown below with a simple device driver that installs GPE handler in the attach routine, and does nothing else than waiting for GPEs. No matter if I try to handle it sync (calling SPIBUS_TRANSFER() from the handler), or async (calling taskqueue_enqueue()), once one of those functions called from the handler does mtx_lock(), it panics. Any hints? panic: mtx_lock() by idle thread 0xfffff800035bb000 on sleep mutex spi1 @ /home/yuri/ws/mbp/sys/dev/intel/spi.c:382 cpuid = 0 time = 1536642645 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00764761b0 vpanic() at vpanic+0x1a3/frame 0xfffffe0076476210 panic() at panic+0x43/frame 0xfffffe0076476270 __mtx_lock_flags() at __mtx_lock_flags+0x15a/frame 0xfffffe00764762c0 intelspi_transfer() at intelspi_transfer+0x3d/frame 0xfffffe0076476310 spimbp_gpe_handler() at spimbp_gpe_handler+0x102/frame 0xfffffe0076476580 AcpiEvGpeDispatch() at AcpiEvGpeDispatch+0xc0/frame 0xfffffe00764765b0 AcpiEvDetectGpe() at AcpiEvDetectGpe+0x10a/frame 0xfffffe0076476600 AcpiEvGpeDetect() at AcpiEvGpeDetect+0x323/frame 0xfffffe0076476670 AcpiEvSciXruptHandler() at AcpiEvSciXruptHandler+0x1e/frame 0xfffffe00764766a0 acpi_intr_handler() at acpi_intr_handler+0x18/frame 0xfffffe00764766b0 intr_event_handle() at intr_event_handle+0xcb/frame 0xfffffe0076476700 intr_execute_handlers() at intr_execute_handlers+0x58/frame 0xfffffe0076476730 lapic_handle_intr() at lapic_handle_intr+0x5f/frame 0xfffffe0076476750 Xapic_isr1() at Xapic_isr1+0xd9/frame 0xfffffe0076476750 --- interrupt, rip = 0xffffffff80461191, rsp = 0xfffffe0076476820, rbp = 0xfffffe0076476860 --- acpi_cpu_idle() at acpi_cpu_idle+0x2a1/frame 0xfffffe0076476860 cpu_idle_acpi() at cpu_idle_acpi+0x3f/frame 0xfffffe0076476880 cpu_idle() at cpu_idle+0xa7/frame 0xfffffe00764768a0 sched_idletd() at sched_idletd+0x517/frame 0xfffffe0076476970 fork_exit() at fork_exit+0x84/frame 0xfffffe00764769b0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00764769b0 --- trap 0, rip = 0, rsp = 0, rbp = 0 --- KDB: enter: panic From owner-freebsd-hackers@freebsd.org Tue Sep 11 05:23:05 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D06D410A977E for ; Tue, 11 Sep 2018 05:23:04 +0000 (UTC) (envelope-from robert.ayrapetyan@gmail.com) Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47D9485FB3; Tue, 11 Sep 2018 05:23:04 +0000 (UTC) (envelope-from robert.ayrapetyan@gmail.com) Received: by mail-pl1-x632.google.com with SMTP id f6-v6so10794720plo.1; Mon, 10 Sep 2018 22:23:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=N+O+NpySufrmgzVaptep8X2S5MGA+Qk6b9wKglhpPhU=; b=k2s8YEhK5RsyU3MqG+NcCCFDwuwyT/ix+ZgpHhK88bnUXPRG1M3IoVpRTkZbG/Y3O/ oBAr59svlGMSIvCgVHwqLaA9w/qX/jhH0Gekbs/dvmhDvMOx9ewZPm1MMV0E1H6pUpbq 9y443ZRth6JPNp41EUgMbKbgTkg1mCHRVLCmLok95yMxzlnLPQwk+ZzBsiFjoTBYPV/H G39kiDUF59uyfe1bq/p7QMBCszsm/pj3kpqci9AvFi9QRCXeM9paKC6cpCzu6CX9pqFs YH2TEktH+2YWtpJBDHhssTZbNJ2kbqPyNulh2ViMaAfrOV6oSCjxj7oafSH5NZmnqi7q u3fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=N+O+NpySufrmgzVaptep8X2S5MGA+Qk6b9wKglhpPhU=; b=Q6agaV/yh32d9F5NlibYH01g/i179AQY+3oLUSDJnC3Vw3jkxj/qcMrys4Y9cSo7gy 13HzJSoTns4PXoEgr6rtfdA/ZX6LDnvMXWC+EdzxM9c2XhEz5RnGoPdygrt8MISPm4no 9biqNk/+z2fEs8aAAHsCDPyppmPcSV+jML1AkbdsRgj67lSLdHlBUGF1u0GBcMRlm1vE nKKlxMROzaAI3GGNCRRpfZRMCt3KDP+LPcDAPFPxXxOuPcy2v7awTDPkXK1PTiR6++D8 nv/N6tSJcnuWhsmC42CEpnSK+W9Fb85b6CV2qcDdYKLYQz//kPbE8KMOv5lOZKxBifZO DJlA== X-Gm-Message-State: APzg51COw9KImckFxTVDqzZ9mnty5wEwWxe2UEww8ZlpSqLJoHyX6vHN O9hOKqXF6xU58Vu9+syjNPNU32GCMA== X-Google-Smtp-Source: ANB0VdYRxEWZXB2TwVA0ft19WLnYrodGM9vHpxKI5trXF1lcQcbegnSJyp1k4NFko3nwe8ToDyKq6g== X-Received: by 2002:a17:902:344:: with SMTP id 62-v6mr25501980pld.164.1536643382813; Mon, 10 Sep 2018 22:23:02 -0700 (PDT) Received: from [192.168.1.113] (c-73-202-42-181.hsd1.ca.comcast.net. [73.202.42.181]) by smtp.gmail.com with ESMTPSA id s195-v6sm40230996pgs.76.2018.09.10.22.23.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Sep 2018 22:23:02 -0700 (PDT) Subject: Re: Sudden grow of memory in "Laundry" state From: Robert To: Mark Johnston Cc: freebsd-hackers@freebsd.org References: <55b0dd7d-19a3-b566-0602-762b783e8ff3@gmail.com> <20180911005411.GF2849@raichu> Message-ID: <9587adab-2084-9fc1-df75-254d9f17fecb@gmail.com> Date: Mon, 10 Sep 2018 22:23:01 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2018 05:23:05 -0000 sysctl vm.stats vm.stats.object.bypasses: 44686 vm.stats.object.collapses: 1635786 vm.stats.misc.cnt_prezero: 0 vm.stats.misc.zero_page_count: 29511 vm.stats.vm.v_kthreadpages: 0 vm.stats.vm.v_rforkpages: 0 vm.stats.vm.v_vforkpages: 738592 vm.stats.vm.v_forkpages: 15331959 vm.stats.vm.v_kthreads: 25 vm.stats.vm.v_rforks: 0 vm.stats.vm.v_vforks: 21915 vm.stats.vm.v_forks: 378768 vm.stats.vm.v_interrupt_free_min: 2 vm.stats.vm.v_pageout_free_min: 34 vm.stats.vm.v_cache_count: 0 vm.stats.vm.v_laundry_count: 6196772 vm.stats.vm.v_inactive_count: 2205526 vm.stats.vm.v_inactive_target: 390661 vm.stats.vm.v_active_count: 3163069 vm.stats.vm.v_wire_count: 556447 vm.stats.vm.v_free_count: 101235 vm.stats.vm.v_free_min: 77096 vm.stats.vm.v_free_target: 260441 vm.stats.vm.v_free_reserved: 15981 vm.stats.vm.v_page_count: 12223372 vm.stats.vm.v_page_size: 4096 vm.stats.vm.v_tfree: 61213188 vm.stats.vm.v_pfree: 24438917 vm.stats.vm.v_dfree: 1936826 vm.stats.vm.v_tcached: 0 vm.stats.vm.v_pdshortfalls: 12 vm.stats.vm.v_pdpages: 1536983413 vm.stats.vm.v_pdwakeups: 3 vm.stats.vm.v_reactivated: 2621520 vm.stats.vm.v_intrans: 12150 vm.stats.vm.v_vnodepgsout: 0 vm.stats.vm.v_vnodepgsin: 16016 vm.stats.vm.v_vnodeout: 0 vm.stats.vm.v_vnodein: 1782 vm.stats.vm.v_swappgsout: 1682860 vm.stats.vm.v_swappgsin: 6368 vm.stats.vm.v_swapout: 61678 vm.stats.vm.v_swapin: 1763 vm.stats.vm.v_ozfod: 21498 vm.stats.vm.v_zfod: 36072114 vm.stats.vm.v_cow_optim: 5912 vm.stats.vm.v_cow_faults: 18880051 vm.stats.vm.v_io_faults: 3165 vm.stats.vm.v_vm_faults: 705101188 vm.stats.sys.v_soft: 470906002 vm.stats.sys.v_intr: 3743337461 vm.stats.sys.v_syscall: 3134154383 vm.stats.sys.v_trap: 590473243 vm.stats.sys.v_swtch: 1037209739 On 09/10/18 22:18, Robert wrote: > Hi, if I understood correctly, "written back to swap device" means > they come from swap at some point, but it's not the case (see attached > graph). > > Swap was 16GB, and slightly reduced when pages rapidly started to move > from free (or "Inactive"?) into "Laundry" queue. > > Here is vmstat output: > > vmstat -s > 821885826 cpu context switches > 3668809349 device interrupts > 470487370 software interrupts > 589970984 traps > 3010410552 system calls >        25 kernel threads created >    378438  fork() calls >     21904 vfork() calls >         0 rfork() calls >      1762 swap pager pageins >      6367 swap pager pages paged in >     61678 swap pager pageouts >   1682860 swap pager pages paged out >      1782 vnode pager pageins >     16016 vnode pager pages paged in >         0 vnode pager pageouts >         0 vnode pager pages paged out >         3 page daemon wakeups > 1535368624 pages examined by the page daemon >        12 clean page reclamation shortfalls >   2621520 pages reactivated by the page daemon >  18865126 copy-on-write faults >      5910 copy-on-write optimized faults >  36063024 zero fill pages zeroed >     21137 zero fill pages prezeroed >     12149 intransit blocking page faults > 704496861 total VM faults taken >      3164 page faults requiring I/O >         0 pages affected by kernel thread creation >  15318548 pages affected by  fork() >    738228 pages affected by vfork() >         0 pages affected by rfork() >  61175662 pages freed >   1936826 pages freed by daemon >  24420300 pages freed by exiting processes >   3164850 pages active >   2203028 pages inactive >   6196772 pages in the laundry queue >    555637 pages wired down >    102762 pages free >      4096 bytes per page > 2493686705 total name lookups >           cache hits (99% pos + 0% neg) system 0% per-directory >           deletions 0%, falsehits 0%, toolong 0% > > What do you think? How pages could be moved into "Laundry" without > being in Swap? > > Thanks. > > > On 09/10/18 17:54, Mark Johnston wrote: >> On Mon, Sep 10, 2018 at 11:44:52AM -0700, Robert wrote: >>> Hi, I have a server with FreeBSD 11.2 and 48 Gigs of RAM where an app >>> with extensive usage of shared memory (24GB allocation) is running. >>> >>> After some random amount of time (usually few days of running), there >>> happens a sudden increase of "Laundry" memory grow (from zero to 24G in >>> a few minutes). >>> >>> Then slowly it reduces. >>> >>> Are described symptoms normal and expected? I've never noticed anything >>> like that on 11.1. >> The laundry queue contains dirty inactive pages, which need to be >> written back to the swap device or a filesystem before they can be >> reused.  When the system is short for free pages, it will scan the >> inactive queue looking for clean pages, which can be freed cheaply. >> Dirty pages are moved to the laundry queue.  My guess is that the >> system was running without a page shortage for a long time, and >> suddenly experienced some memory pressure.  This caused lots of >> pages to move from the inactive queue to the laundry queue. Demand >> for free pages will then cause pages in the laundry queue to be >> written back and freed, or requeued if the page was referenced after >> being placed in the laundry queue.  "vmstat -s" and "sysctl vm.stats" >> output might make things more clear. >> >> All this is to say that there's nothing particularly abnormal about what >> you're observing, though it's not clear what effects this behaviour has >> on your workload, if any.  I can't think of any direct reason this would >> happen on 11.2 but not 11.1. > From owner-freebsd-hackers@freebsd.org Tue Sep 11 08:44:09 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8E8901089583 for ; Tue, 11 Sep 2018 08:44:09 +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 19E318C82F for ; Tue, 11 Sep 2018 08:44:08 +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 w8B8hv1b086608 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 11 Sep 2018 11:44:01 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w8B8hv1b086608 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w8B8hv5t086607; Tue, 11 Sep 2018 11:43:57 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 11 Sep 2018 11:43:57 +0300 From: Konstantin Belousov To: Yuri Pankov Cc: freebsd-hackers Subject: Re: ACPI GPE handler: mtx_lock() by idle thread Message-ID: <20180911084357.GU3161@kib.kiev.ua> References: <475afc8c-d0ad-ead2-e75e-bca873977c2d@yuripv.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <475afc8c-d0ad-ead2-e75e-bca873977c2d@yuripv.net> User-Agent: Mutt/1.10.1 (2018-07-13) 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.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2018 08:44:09 -0000 On Tue, Sep 11, 2018 at 08:19:26AM +0300, Yuri Pankov wrote: > I have the panic shown below with a simple device driver that installs > GPE handler in the attach routine, and does nothing else than waiting > for GPEs. No matter if I try to handle it sync (calling > SPIBUS_TRANSFER() from the handler), or async (calling > taskqueue_enqueue()), once one of those functions called from the > handler does mtx_lock(), it panics. Any hints? If you look at the backtrace below, you would note that ACPI GPE event handler is executed in the context of an interrupt. It means that it borrows the context of whatever thread was executed on the CPU when the interrupt occured. One of the consequences is that an interrupt handler (fast interrupt handler in the FreeBSD terminology) cannot block or sleep, see locking(9). There is a different way to handle interrupts in FreeBSD, by normal (not fast) interrupt handlers. There, the code executing in the context of interrupt only wakes up the interrupt thread, which executes the handler in its dedicated context. As the consequence, mutexes do work for such handlers. Still, sleep is prohibited. I briefly looked at the dev/intel/spi.c code and I see that intelspi_transfer() sleeps waiting for the hardware event. In other words, even normal interrupt handler cannot help your problem. Is it required to do the transfers in the interrupt handler code, for your work ? If not, then the usual solution is to delegate the work that requires resource acquision, to the fast taskqueue. Your code in GPE event handler would only schedule a task, and the running task can do whatever slow operations it needs. See taskqueue(9), there are enough examples of the fast taskqueue use in the tree. > > > panic: mtx_lock() by idle thread 0xfffff800035bb000 on sleep mutex spi1 > @ /home/yuri/ws/mbp/sys/dev/intel/spi.c:382 > cpuid = 0 > time = 1536642645 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > 0xfffffe00764761b0 > vpanic() at vpanic+0x1a3/frame 0xfffffe0076476210 > panic() at panic+0x43/frame 0xfffffe0076476270 > __mtx_lock_flags() at __mtx_lock_flags+0x15a/frame 0xfffffe00764762c0 > intelspi_transfer() at intelspi_transfer+0x3d/frame 0xfffffe0076476310 > spimbp_gpe_handler() at spimbp_gpe_handler+0x102/frame 0xfffffe0076476580 > AcpiEvGpeDispatch() at AcpiEvGpeDispatch+0xc0/frame 0xfffffe00764765b0 > AcpiEvDetectGpe() at AcpiEvDetectGpe+0x10a/frame 0xfffffe0076476600 > AcpiEvGpeDetect() at AcpiEvGpeDetect+0x323/frame 0xfffffe0076476670 > AcpiEvSciXruptHandler() at AcpiEvSciXruptHandler+0x1e/frame > 0xfffffe00764766a0 > acpi_intr_handler() at acpi_intr_handler+0x18/frame 0xfffffe00764766b0 > intr_event_handle() at intr_event_handle+0xcb/frame 0xfffffe0076476700 > intr_execute_handlers() at intr_execute_handlers+0x58/frame > 0xfffffe0076476730 > lapic_handle_intr() at lapic_handle_intr+0x5f/frame 0xfffffe0076476750 > Xapic_isr1() at Xapic_isr1+0xd9/frame 0xfffffe0076476750 > --- interrupt, rip = 0xffffffff80461191, rsp = 0xfffffe0076476820, rbp = > 0xfffffe0076476860 --- > acpi_cpu_idle() at acpi_cpu_idle+0x2a1/frame 0xfffffe0076476860 > cpu_idle_acpi() at cpu_idle_acpi+0x3f/frame 0xfffffe0076476880 > cpu_idle() at cpu_idle+0xa7/frame 0xfffffe00764768a0 > sched_idletd() at sched_idletd+0x517/frame 0xfffffe0076476970 > fork_exit() at fork_exit+0x84/frame 0xfffffe00764769b0 > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00764769b0 > --- trap 0, rip = 0, rsp = 0, rbp = 0 --- > KDB: enter: panic From owner-freebsd-hackers@freebsd.org Tue Sep 11 10:27:35 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B067B108C353 for ; Tue, 11 Sep 2018 10:27:35 +0000 (UTC) (envelope-from mpp302@gmail.com) Received: from mail-qt0-f169.google.com (mail-qt0-f169.google.com [209.85.216.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5127D710C5; Tue, 11 Sep 2018 10:27:35 +0000 (UTC) (envelope-from mpp302@gmail.com) Received: by mail-qt0-f169.google.com with SMTP id r37-v6so27616236qtc.0; Tue, 11 Sep 2018 03:27:35 -0700 (PDT) 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:cc; bh=QSRO40+M3M/xdJzlxY92Bv9p1vQCncouNEGRb7V6rtI=; b=WE1T/9Pi/SphayssLpOg3RXs5f775WeRq5jhnY1ZuIy+KswxYnf+JTLqv3zc4YkKvr vp3PM3lqrXIKXjylJDSuE791R870CpMGyRnVcs0mWWlPiLm3wJkrs6vSRiOhxTUGplq4 9jUeEy4oSGOg0L988JtEFGYVHt5t0SGIgGcbHhKVu+rVjHhK3IlsgU0yv03/OuPAU8lT je+vkFpYcSdJ8S/rIZmFli7M+v/jcnQ1lu1hzhAAFDa7fIGJpjJm6mzAIsLoQbIg07QN cdSivJJ8TJu+p3jKcwO0w7uZY6TFbGWibM+ntvCbPdtkyZ7YI85GoSxL88+cAmCUeSl2 BqTw== X-Gm-Message-State: APzg51BSt3xz/ztV192LvjyKJXeH9WUOb+a3P538mplfnF+rP9COu+rp ajqdNXU4JlHI9edRuVnpWNdILnghzwBAyQ== X-Google-Smtp-Source: ANB0VdYRVaE5ba5Ely90vS/0FMoAqWq1W8jezvjUzo8nXk4muKk/vtc7AwlahZQB7WdjE4dc5y84cg== X-Received: by 2002:a0c:88ad:: with SMTP id 42-v6mr17989729qvn.79.1536660156266; Tue, 11 Sep 2018 03:02:36 -0700 (PDT) Received: from mail-qt0-f180.google.com (mail-qt0-f180.google.com. [209.85.216.180]) by smtp.gmail.com with ESMTPSA id x76-v6sm11475118qkx.25.2018.09.11.03.02.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Sep 2018 03:02:36 -0700 (PDT) Received: by mail-qt0-f180.google.com with SMTP id g53-v6so27491150qtg.10; Tue, 11 Sep 2018 03:02:35 -0700 (PDT) X-Received: by 2002:ac8:1978:: with SMTP id g53-v6mr19605329qtk.193.1536660155671; Tue, 11 Sep 2018 03:02:35 -0700 (PDT) MIME-Version: 1.0 From: Mateusz Piotrowski <0mp@freebsd.org> Date: Tue, 11 Sep 2018 12:02:29 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Let's improve splash screen support in vt(4) To: FreeBSD Hackers Cc: emaste@freebsd.org, dumbbell@freebsd.org, cperciva@freebsd.org, royger@freebsd.org, nwhitehorn@freebsd.org, ed@freebsd.org, ray@dlink.ua, wblock@freebsd.org, r.fernandez-cueto@bally-wulff.de X-Mailman-Approved-At: Tue, 11 Sep 2018 10:37:51 +0000 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2018 10:27:36 -0000 Hello, I'd like to improve splash screen support in vt(4) and I'm looking for your guidance and suggestions. Background ---------- As you may know, vt(4) does not support custom splash screens at the moment.[1][2][3] As splash screen could be turned on by specifying the -m flag to boot(8). It cannot be customized, however: the displayed image, its colors and size are set at compile time. Goals ----- - Support for BMP files so that they could be specified in loader.conf(5) (similarly to how it is done when using sc(4) and splash(4)). - Kernel tunables to control colors of the displayed image. Basically, I'd like to "unhardcode" colors used for vt(4) splash screens. Proposed implementation ----------------------- Unhardcoding colors seems to be an easy task: from what I understand it all boils down to adding a couple of sysctls. This way a user might choose which colors of the vt(4) color pallet should be used for the splash image. The more challenging part is getting raw data from a bitmap file in the vt(4) driver. I've done some research and I think that the easiest solution would be to use the existing splash(4) driver to extract data from a BMP file as drawing functions in vt(4) expect raw data. We could use splash(4) to load the file and put it into a C structure, which would then be accessible in vt(4) via a to-be-written interface. This approach does not feel super clean so this I decided to ask you if you've got any suggestions on how to improve this solution. Stretched goals -------------- At first I thought that adding support for 8-bit colors is not going to be a big problem. Then I found out that the vd_bitblt_bmp function expect exactly two colors (1 for foreground and 1 for background). I'll have to do more research if I want to support bitmaps with an 8-bit color depth. I'll be grateful for al suggestions, hints and pieces of advice. ---- The wiki page of this project is here: https://wiki.freebsd.org/MateuszPiotrowski/ImproveVtSplashScreenSupport Thanks & happy hacking, Mateusz [1]: https://wiki.freebsd.org/Newcons [2]: https://svnweb.freebsd.org/base/head/sys/dev/vt/vt_core.c?revision=338324&view=markup#l142 [3]: https://svnweb.freebsd.org/base/head/sys/dev/vt/vt_core.c?revision=338324&view=markup#l1373 From owner-freebsd-hackers@freebsd.org Tue Sep 11 10:44:12 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AC899108CC14 for ; Tue, 11 Sep 2018 10:44:12 +0000 (UTC) (envelope-from churchers@gmail.com) Received: from mail-ua1-x929.google.com (mail-ua1-x929.google.com [IPv6:2607:f8b0:4864:20::929]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 426F871C55 for ; Tue, 11 Sep 2018 10:44:12 +0000 (UTC) (envelope-from churchers@gmail.com) Received: by mail-ua1-x929.google.com with SMTP id r15-v6so20075817uao.1 for ; Tue, 11 Sep 2018 03:44:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=g4W6FxsFR8/7/r7rOLw0uu54NgQdRFQzb8r1QkauqR0=; b=e0djroLiup/h6LVzCbhjKGW0h0ziEf5mrRGiTJU2BQIqMf2yveXwnfiWEYn0MiDRO1 E2rcK1QBCNcrPmbtjjZlvtcGIRR9FkTXvaWHt/flzvP4F0GJ/rRXhOGSetlWF0Pjtchf u27pkexVO1IA2dIJp2Y6TZi3krllN+DEpuC5qFls6LPuUWryKuzW8Z2Rt3b7qhuFiiOU EuuloHmT4jZIEv3S/spmKV24TAQotuBbyi3Jhs+Ly0D2/qS2CFeLprNnx9ZrErNq7UPQ DH+QztacajDQsbjdayz4B3OVlDwF0uM7utBum54x9M139/m8rEPtxfwkaqD7lBPJzaXE /AuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=g4W6FxsFR8/7/r7rOLw0uu54NgQdRFQzb8r1QkauqR0=; b=tsDm4Pm5VQMpcbGjcoD31Wv/sfpL56EV+Y/m9Tfj1pCVVs1FvLXzoNr4Uw0dQR/4Wn au5fXNwqLJgdpqImPIGlVOx2muoouckS/qqrJFwfaWv2M0KazXu/DJeWXWmVyeYZt8OG jVO6x06QucZrEUJCTZL3I9pI42x9ODHFf7qxOlvM3mYrXX+/Xrue3kLeiqfCGCEoWspc I300NWK+3mZ+CanR4Lp4Spr1D8Pl18/u/z8mBdCLXnNxF/2RHHI9+D1xZPLL1PkY+CCs NmauhUlDnjGbXVbwfuIPfx+FmgID4MHeO9sNAFtZ6NypBBabMGilACT78hQcbc0b4h1H dh9g== X-Gm-Message-State: APzg51CyVUGllo1fIqlstwtPZmYCJtWPOcMzgn1a8sGQOtMEwTpgr5d/ ZDod5rIgbiqU6awB9cvU069Pegpl5ME7lcgCXrp0oGNyQ64= X-Google-Smtp-Source: ANB0VdZrsYMAI0eS9zvKCF0pno1Es8kjrSW2LcuN8uIbAY71wQ63MGOqeL001TUqH2Q3M1hzNupeaA/fuU5/mR8OMHc= X-Received: by 2002:ab0:144a:: with SMTP id c10-v6mr8459200uae.65.1536662651526; Tue, 11 Sep 2018 03:44:11 -0700 (PDT) MIME-Version: 1.0 References: <201809110129.w8B1TG1Z022255@idle.juniper.net> In-Reply-To: <201809110129.w8B1TG1Z022255@idle.juniper.net> From: Matt Churchyard Date: Tue, 11 Sep 2018 11:44:15 +0100 Message-ID: Subject: Re: Getting valid JSON output with xo(1) To: phil@juniper.net Cc: freebsd-hackers@freebsd.org, sjg@juniper.net X-Mailman-Approved-At: Tue, 11 Sep 2018 11:00:37 +0000 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2018 10:44:12 -0000 Hi Phil, Thanks for the detailed response. The part about HTML makes perfect sense. Each outer div is a "line", so without the "\n", you may well want to create further output on the same line by making additional calls. (Assuming of course that you can use the --not-first option to stop it creating another "line" div) As you mention, the fact that xo(1) is designed to be called multiple times in order to build up the output from fragments makes some of this stuff awkward. Thanks for pointing out the --not-first option. I think the sample from #61 looks fairly reasonable. Not that I want to create you guys extra work..., I've no doubt your primary focus is libxo itself which already works fine. Just seems that the xo command line utility is quite hampered if it can't create lists (in JSON at least). At the moment I'm getting around it fairly simply by using something like the following, (the tr calls fortunately only have an effect on JSON output.), which works, but is a lot of jumping through hoops just to get valid JSON. xo -pJ --open machines | tr '{' '[' (if JSON & not first) echo "," (if JSON) echo "{" (if JSON) xo -pJ "{:key1}{:key2}{:key3}" data1 data2 data3 (if not JSON) xo -pJ --wrap machine "{:key1}{:key2}{:key3}" data1 data2 data3 (if JSON) echo "}" xo -pJ --close machines | tr '}' ']' Regards, Matt On Tue, Sep 11, 2018 at 2:28 AM Phil Shafer wrote: > Matt Churchyard writes: > >Sorry if this is the wrong list, I wasn't sure which was the most > >appropriate. > > Best path for xo-related bugs is https://github.com/Juniper/libxo/issues > Email directly to phil@ is also reasonable. > > >If I choose HTML output I get the following invalid output which is > missing > >closing
tags. > > > >
> >
test1
> >
,
> >
2GB
> >
> >
test2
> >
,
> >
4GB
> > > >This can be fixed by adding "\n" to the end of the format lines, which may > >be required, but it seems strange that I can so easily generate broken > >output. > > Yes, without a trailing newline, libxo can't declare the output > line "over", so it doesn't make the
. The problem is that > there's no mechanism to "xo" that your output line is continued > from the previous one, and since "xo" is stateless, it will happily > start the next chunk of output with a new open div. I'll add a > "--continuation" option. (#58) > > >"bhyve": { > > "machines": { > > "machine": { > > "name": "test1", > > "memory": "2GB" > > } "machine": { > > "name": "test2", > > "memory": "4GB" > > } > > } > >} > > There's an "xo" option called "--not-first" for exactly these > situations; place that option on the second invocation so it will > know to emit the leading comma. This should be documented (#59). > > >1) The entire document needs to be inside braces "{}" so that "bhyve" is a > >member of an object. > > "xo" doesn't currently do this, since it assume you're generating > JSON piecemeal and have a better idea that it of what you want > to do with the output, but I've opened issue #60 for adding > a "--object-wrapper" option that will perform this. > > >2) There's a missing comma between the two machine entries > > The "--not-first" option will repair this. > > >3) "machines" is an object, which erroneously contains 2 "machine" keys > > This is a bug. "xo" lacks a means of knowing that an object is a > list. One might expect that labeling "name as a key would perform > this, but it doesn't, and it's not clear that this is enough > information. Since "xo" is stateless, it cannot really handle > that "--wrapper machine" applies only to the first item. It > would have to know not to generate the closing "}" for machine, > but it's stateless, so I'd need a means of telling it that. > > In C code, we have "xo_open_list" and "xo_open_instance", like: > > > https://libxo.readthedocs.io/en/latest/api.html?highlight=xo_open_instance#lists-and-instances > > But with "xo" I don't have lists and instances. I'll need to > find a means of adding these, though that would make "xo" more > cumbersome and it would lack the FSM (and the stack) that catches > missing calls in libxo. > > xo $opts --open-list machine > for name in red green blue; do > xo $opts --open-instance machine > xo $opts "Machine {k:name} has {:memory}\n" $name `get-mem ~name` > xo $opts --close-instance machine > done > xo $opts --close-list machine > > Which is very exact but less that beautiful. This is #61. > > Thanks, > Phil > From owner-freebsd-hackers@freebsd.org Tue Sep 11 11:46:05 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6DD84108E270 for ; Tue, 11 Sep 2018 11:46:05 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 0F340737C2; Tue, 11 Sep 2018 11:46:04 +0000 (UTC) (envelope-from des@des.no) Received: from next.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id D2ECA8872; Tue, 11 Sep 2018 11:46:03 +0000 (UTC) Received: by next.des.no (Postfix, from userid 1001) id 2D5E38F12; Tue, 11 Sep 2018 13:46:04 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Mateusz Piotrowski <0mp@freebsd.org> Cc: FreeBSD Hackers Subject: Re: Let's improve splash screen support in vt(4) In-Reply-To: (Mateusz Piotrowski's message of "Tue, 11 Sep 2018 12:02:29 +0200") References: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (berkeley-unix) Date: Tue, 11 Sep 2018 13:46:04 +0200 Message-ID: <86va7cs1dv.fsf@next.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2018 11:46:05 -0000 Mateusz Piotrowski <0mp@freebsd.org> writes: > I'd like to improve splash screen support in vt(4) [...] Let me know if you get it working, because I'd like to get graphical screensavers to work with vt(4) as well. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@freebsd.org Tue Sep 11 15:08:55 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DEEEC1093FBF for ; Tue, 11 Sep 2018 15:08:54 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5649B7AFED for ; Tue, 11 Sep 2018 15:08:54 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-pg1-x534.google.com with SMTP id b129-v6so12396677pga.13 for ; Tue, 11 Sep 2018 08:08:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=QGKTaEkkf1HNlxCS8dbiIESZAcEdd+aG5ShW+GZdQEU=; b=TIbDY2aM8sDCOFvd/BwfrUnfgeqS4w9CrA9cEqY1uToyW12QTcU8/L89citFFhBKio 7nSDteD2HuTk5VazupaDTjY4vJruqxCbjKm8usvDGEsPby1NKu581Elq1I0frhXTdxLD uv+tjGOIMbcmrxejxzZvOlUNTAFQr1tgWNUwEWbb8fQ3pouOs9HkpP2s3rJV+6XczfWh MMle1CatXYVcAqmPeyybqoVh2/5fixnoJT22u5InXay/m+8BEjrk2nZrBAiknh6+Jehr Aq8q92o4uo14wvaDyWcozF36TMo+IyRggFcC0eL0V+ZsZbrxyIID/TRGFA7Np6z0Tv2v 7Hew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=QGKTaEkkf1HNlxCS8dbiIESZAcEdd+aG5ShW+GZdQEU=; b=Jarpbj1ncF54P5vGtkLGONkzm9UqS0IaybvvzZ+P13XEWCOwuYNLg6lBiNMak7ay3q WclxTjNltNe5vJz57HKbeawTFo1lskE/ydQPS2xvBqijPoe1hPjHqwGGARyNLapJzP7p ZP1NzZZQ1wFZzOD6o4xPMO004SDnUvNoVkcgq1vevPhMTvsS1R0pcnMeuxM3MJRVSEoU b5Smukhqr139jcaYIz/aipu07XySQ8kCPC5RZ9V0t3bUb3Im6aV4dFcnVz5LjW7WXWLv HRUQRsR+Us7ZMXe1ekHuK2lURtKEba+Y5q4dkjXGJeEw3b9nnY9htiTo496zmkIA0LrT 6LlQ== X-Gm-Message-State: APzg51BUxMNDz/88g9VnQdVIk9O2+GKQk4jxTPBf0JcXrAu43HRIPG2W Wc3kXanWl9A9kDLgrLIaBuU= X-Google-Smtp-Source: ANB0VdbfkPFP2z9gJHzs9ZyjbPO+nTFg7S6Th5p9OTp2wT7USD/vpgoYMwGbBdRtNYv4Mbus1CMWjA== X-Received: by 2002:a63:1947:: with SMTP id 7-v6mr29025484pgz.192.1536678533262; Tue, 11 Sep 2018 08:08:53 -0700 (PDT) Received: from raichu (toroon0560w-lp130-01-174-88-78-8.dsl.bell.ca. [174.88.78.8]) by smtp.gmail.com with ESMTPSA id r64-v6sm30539956pfk.157.2018.09.11.08.08.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Sep 2018 08:08:52 -0700 (PDT) Sender: Mark Johnston Date: Tue, 11 Sep 2018 11:08:49 -0400 From: Mark Johnston To: Robert Cc: freebsd-hackers@freebsd.org Subject: Re: Sudden grow of memory in "Laundry" state Message-ID: <20180911150849.GD92634@raichu> References: <55b0dd7d-19a3-b566-0602-762b783e8ff3@gmail.com> <20180911005411.GF2849@raichu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2018 15:08:55 -0000 On Mon, Sep 10, 2018 at 10:18:31PM -0700, Robert wrote: > Hi, if I understood correctly, "written back to swap device" means they > come from swap at some point, but it's not the case (see attached graph). Sorry, I didn't mean to imply that. Pages containing your application's shared memory, for instance, would simply be written to the swap device before being freed and reused for some other purpose. Your graph shows a sudden drop in free memory. Does that coincide with the sudden increase in size of the laundry queue? > Swap was 16GB, and slightly reduced when pages rapidly started to move > from free (or "Inactive"?) into "Laundry" queue. Right. Specifically, the amount of free swap space decreased right at the time that the amount of free memory dropped, so what likely happened is that the system wrote some pages in "Laundry" to the swap device so that they could be freed, as a response to the drop in free memory. > Here is vmstat output: > > vmstat -s > [...] > 12 clean page reclamation shortfalls This line basically means that at some point we were writing pages to the swap device as fast as possible in order to reclaim some memory. > What do you think? How pages could be moved into "Laundry" without being > in Swap? That's perfectly normal. Pages typically move from "Active" or "Inactive" to laundry. > > On 09/10/18 17:54, Mark Johnston wrote: > > On Mon, Sep 10, 2018 at 11:44:52AM -0700, Robert wrote: > >> Hi, I have a server with FreeBSD 11.2 and 48 Gigs of RAM where an app > >> with extensive usage of shared memory (24GB allocation) is running. > >> > >> After some random amount of time (usually few days of running), there > >> happens a sudden increase of "Laundry" memory grow (from zero to 24G in > >> a few minutes). > >> > >> Then slowly it reduces. > >> > >> Are described symptoms normal and expected? I've never noticed anything > >> like that on 11.1. > > The laundry queue contains dirty inactive pages, which need to be > > written back to the swap device or a filesystem before they can be > > reused. When the system is short for free pages, it will scan the > > inactive queue looking for clean pages, which can be freed cheaply. > > Dirty pages are moved to the laundry queue. My guess is that the > > system was running without a page shortage for a long time, and > > suddenly experienced some memory pressure. This caused lots of > > pages to move from the inactive queue to the laundry queue. Demand > > for free pages will then cause pages in the laundry queue to be > > written back and freed, or requeued if the page was referenced after > > being placed in the laundry queue. "vmstat -s" and "sysctl vm.stats" > > output might make things more clear. > > > > All this is to say that there's nothing particularly abnormal about what > > you're observing, though it's not clear what effects this behaviour has > > on your workload, if any. I can't think of any direct reason this would > > happen on 11.2 but not 11.1. > From owner-freebsd-hackers@freebsd.org Tue Sep 11 17:39:50 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 47E081097C84 for ; Tue, 11 Sep 2018 17:39:50 +0000 (UTC) (envelope-from yuripv@yuripv.net) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (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 C368580FA0 for ; Tue, 11 Sep 2018 17:39:49 +0000 (UTC) (envelope-from yuripv@yuripv.net) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 33D6D3B9; Tue, 11 Sep 2018 13:39:48 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Tue, 11 Sep 2018 13:39:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yuripv.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=+qJFhsd4dNZnn0vZEFoyMedUDe2Ta /QHqsSSkKn6/TM=; b=kDlsb+D6EBDaQAZ0yaLMG4EtKTiHNWK5/uA2RbZDwt+Ep mLVfBmc9WTJtahJhB45nZAmfGkQ9N/5q178KXhdzVPeLb5uMsGwPHCQrKh7oZ/5P Fbb3vzck4UAZV4PLOPfO5SOAZTqBnB6XFrWGX1HkEjSHdMbqf/2npty+e2WKa2q+ 61ecJxA3SXJ00oPbBrRmOb7nWkkudgy2YGFwNY2TYho6Of2K/p4S7uuTcoezM89U /T5GIBo605Cjg5Jxvh681298yssGpomtd8KmDHhXDGcpGy8sRkqjRo7wHsnmZsic 4P1xkXm7qUxyHWkW41Ed0hhdum4iuIi71PiuOHvbw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=+qJFhs d4dNZnn0vZEFoyMedUDe2Ta/QHqsSSkKn6/TM=; b=cBcbFnMOwoXK0d5dsCYXhW vFWlXiJ7HjqlxqxXsKty53JDdjwgxaDVKXN6KZfGGXR2duPQAQltASSSljnxD0el xRIFp/ykiyo/ffT21nwIKkmq5JXnDvCnJXKHq8svwdj22RPNLrII2CGQJBGImm/D LA6709oJuaUaTKArhxJJxg2Rt40He3uzATtETu0+dCZheAzioQ3JRbqL8qhRczJp qoPGz0rR+YS33/1uj8TblJ7OcF81nj8XQitOeyq1Dh/WO0cSu+3D53Y9eWqyCUcz /5haYDd9l+QPzUwzfHUqwIaoklmrCVhe8JbeUNgq143TbcLJYF/fpNrL78SHz6Hw == X-ME-Proxy: X-ME-Sender: Received: from [192.168.1.2] (unknown [178.34.113.240]) by mail.messagingengine.com (Postfix) with ESMTPA id 306EFE41E6; Tue, 11 Sep 2018 13:39:46 -0400 (EDT) Subject: Re: ACPI GPE handler: mtx_lock() by idle thread To: Konstantin Belousov Cc: freebsd-hackers References: <475afc8c-d0ad-ead2-e75e-bca873977c2d@yuripv.net> <20180911084357.GU3161@kib.kiev.ua> From: Yuri Pankov Message-ID: <8affc553-3db8-fd7f-b8be-c04d1072b84c@yuripv.net> Date: Tue, 11 Sep 2018 20:39:45 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <20180911084357.GU3161@kib.kiev.ua> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2018 17:39:50 -0000 Konstantin Belousov wrote: > On Tue, Sep 11, 2018 at 08:19:26AM +0300, Yuri Pankov wrote: >> I have the panic shown below with a simple device driver that installs >> GPE handler in the attach routine, and does nothing else than waiting >> for GPEs. No matter if I try to handle it sync (calling >> SPIBUS_TRANSFER() from the handler), or async (calling >> taskqueue_enqueue()), once one of those functions called from the >> handler does mtx_lock(), it panics. Any hints? > If you look at the backtrace below, you would note that ACPI GPE event > handler is executed in the context of an interrupt. It means that it > borrows the context of whatever thread was executed on the CPU when the > interrupt occured. One of the consequences is that an interrupt handler > (fast interrupt handler in the FreeBSD terminology) cannot block or > sleep, see locking(9). > > There is a different way to handle interrupts in FreeBSD, by normal (not > fast) interrupt handlers. There, the code executing in the context of > interrupt only wakes up the interrupt thread, which executes the handler > in its dedicated context. As the consequence, mutexes do work for such > handlers. Still, sleep is prohibited. > > I briefly looked at the dev/intel/spi.c code and I see that > intelspi_transfer() sleeps waiting for the hardware event. In other > words, even normal interrupt handler cannot help your problem. > > Is it required to do the transfers in the interrupt handler code, for > your work ? If not, then the usual solution is to delegate the work > that requires resource acquision, to the fast taskqueue. Your code in > GPE event handler would only schedule a task, and the running task can > do whatever slow operations it needs. See taskqueue(9), there are > enough examples of the fast taskqueue use in the tree. Of course, I don't need to process the event in the GPE handler, and just noted that I tried to compare with taskqueue_enqueue()'d async handler, which produced the same results mainly because I was stupid and didn't notice that there's a separate predefined taskqueue for interrupt processing, taskqueue_fast. Now all looks good, I have the chance to do spi transfer in async handler. Thank you for all your help.