From nobody Fri May 21 01:42:20 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0F95D8B12F6 for ; Fri, 21 May 2021 01:42:25 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound4s.ore.mailhop.org (outbound4s.ore.mailhop.org [54.185.97.28]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4FmTr04fJsz4fXW for ; Fri, 21 May 2021 01:42:24 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1621561343; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=aoUBYjbJbBOmXGBY9ApaI2NeGM+kjRG1nMyhA7YLAE8HUvd19PkicmD2S6FokjGPBeMvZd2WAo0MN jMXGHiIIBo1cm7fPbgENhtq4Uk6l6Nq9dkM68BKCVF49C5sFbHAh0bGC6a0YDk7DtewSC4ZSuUuWbD bacI899BT4ng7hXbtQ6D/nIKKIhMwweDMpQVhLoR9vo5Q2cdYg21ZwEr4RcYZ6RBAw0g/Xxl8vDVs6 9+06ufNJcagU5Htl/JdrhvHCMIqniNkcr22iiop1cQA4XGG8gW6Jwnn8DyGAGczJAu0sb9ZDCYCPu8 1LBt5yowTp6xxAZOJiEvNcubf5maSMw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:dkim-signature:from; bh=ZO3W5VL2Q3+QzF7MtQFcyw2JXmQlmsEAzY6J4YuN/hQ=; b=ethcKLxzJkHRESMt21UJ42TyeCabdF8IHelLrSz0pKH+u3e4+CEiS2uXQueKUW2qET7VAld4DL6Lj qEhUl/poxZjHBVH4vO5oCSrQUPiVpPuokg9B3LlbHZNA5PPP8Mx4POBQ3UOREd9H9g6Ee7DR0YE/OO XzndBBNMsXXDzsmX9t52bmGSYVaftuZGgRqTthDdh8J5hpg8SxnxMVX6b4TV8B6n9dTEhhwZTL7Vla GmKQPbehhKlTUUxLNR8eTasJhJgmQgI2j5jegVoyWu+1uHSQauXt9GD3DRJI4uJ+LAegxkBKpreDrB nt309FKdGtJHBQMtQoa2HTxWeNKREpw== ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:from; bh=ZO3W5VL2Q3+QzF7MtQFcyw2JXmQlmsEAzY6J4YuN/hQ=; b=KJhjjLlSxNRQSL/G4ZhvEgB6rUuSTwU1SIn1qZfdesdoJ0AFiynpHRUL0B3TccHVh+UjQAIck/aqF vjNIsndpDFUFcLkQqtFgPZB9jrqHoM8HquuVVG3ZLbHINUcetXVZaHpnpXpic3fwvIBFirAe6fK2GW wAul8FPtM/iHswilPLadGLzGOnYHRYLZU9MKidOcrixMRXdip0h73g8VRlKhjy1ziejQdSvs3Apwok 1OdFLrXkzOYJy4K+KbGVlNxN/B2S6deEiTaIe8HuKCN+qh5rQgndnibhAZ4cM9Y8bv/n/exDc45vnw l9IlJDfo59+S2QDX/zJBb7ypwV/9E2w== X-Originating-IP: 67.177.211.60 X-MHO-RoutePath: aGlwcGll X-MHO-User: c88298e7-b9d5-11eb-a653-89389772cfc7 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (c-67-177-211-60.hsd1.co.comcast.net [67.177.211.60]) by outbound4.ore.mailhop.org (Halon) with ESMTPSA id c88298e7-b9d5-11eb-a653-89389772cfc7; Fri, 21 May 2021 01:42:22 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id 14L1gK7I082024; Thu, 20 May 2021 19:42:20 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <80625b01dd7a2740a23c22370741665e5d2ff6e5.camel@freebsd.org> Subject: Re: Reducing SIGINFO verbosity From: Ian Lepore To: cem@freebsd.org, Michael Gmelin , "freebsd-current@freebsd.org" Date: Thu, 20 May 2021 19:42:20 -0600 In-Reply-To: References: <20210520180155.3e23500e@bsd64.grem.de> <20210520185917.GL14975@funkthat.com> Content-Type: text/plain; charset="iso-8859-7" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4FmTr04fJsz4fXW X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] On Thu, 2021-05-20 at 15:57 -0700, Conrad Meyer wrote: > No, I donĒt think thereĒs any reason to default it differently on > stable vs > current. I think itĒs useful (and I prefer the more verbose form, > which > isnĒt the default). > > Conrad > So... there are thousands of freebsd users, who don't care about this noisy stack trace stuff at all. And there are dozens of freebsd developers, and amongst them there are maybe, what... a half dozen at best that want this info when they hit ^T? So clearly, the right decision is to make maximal noise the default, and not just in the development branches. It doesn't matter how much it bothers the users as long as a few developers are happy. And people moan about freebsd's dwindling user base and wonder why it's withering away. -- Ian > On Thu, May 20, 2021 at 11:59 John-Mark Gurney > wrote: > > > Michael Gmelin wrote this message on Thu, May 20, 2021 at 18:01 > > +0200: > > > I'm leaving this here, mostly so that others (or future me) can > > > google > > > it up. > > > > > > Traditionally, CTRL-t would give a one-line output + whatever the > > > process specific signal handler comes up with: > > > > > > # sleep 120 <--- hits CTRL-t > > > load: 0.27 cmd: sleep 38162 [nanslp] 0.64r 0.00u 0.00s 0% > > > 1780k > > > sleep: about 119 second(s) left out of the original 120 > > > > > > # cat <--- hits CTRL-t > > > load: 0.02 cmd: cat 24379 [ttyin] 0.63r 0.00u 0.00s 0% 2308k > > > > > > > > > On 13 I get: > > > > > > # sleep 120 <--- hits CTRL-t > > > load: 0.12 cmd: sleep 3241 [nanslp] 0.52r 0.00u 0.00s 0% 2172k > > > mi_switch+0xc1 sleepq_catch_signals+0x2e6 > > > sleepq_timedwait_sig+0x12 > > > _sleep+0x199 kern_clock_nanosleep+0x1e1 sys_nanosleep+0x3b > > > amd64_syscall+0x10c fast_syscall_common+0xf8 sleep: about 119 > > > second(s) left out of the original 120 > > > > > > # cat <--- hits CTRL-t > > > load: 0.09 cmd: cat 3240 [ttyin] 0.23r 0.00u 0.00s 0% 2300k > > > mi_switch+0xc1 sleepq_catch_signals+0x2e6 sleepq_wait_sig+0x9 > > > _cv_wait_sig+0xe4 tty_wait+0x1c ttydisc_read+0x2ac > > > ttydev_read+0x56 > > > devfs_read_f+0xd5 dofileread+0x81 sys_read+0xbc > > > amd64_syscall+0x10c > > > fast_syscall_common+0xf8 > > > > > > which is quite way too verbose when checking the progress of > > > long-running processes, like cp, dd, or poudriere. Especially as > > > CTRL-t > > > is part of the user experience to me - I use it to interact with > > > the > > > machine outside of debugging software issues. > > > > > > Setting > > > > > > sysctl kern.tty_info_kstacks=0 > > > echo kern.tty_info_kstacks=0 >>/etc/sysctl.conf > > > > > > fixes this permanently. > > > > > > Apparently, this was enabled by default on purpose[0], so that > > > people > > > find the feature (which certainly worked ^_^), but I think it > > > would > > > been worth mentioning the sysctl somewhere in the release > > > notes/errata, > > > so that people understand how to disable it again. > > > > I think the original intent was to disable this on -stable or at > > least > > -RELEASEs, but it looks like this didn't happen. This is VERY > > helpful > > for a developer, but not as helpful for most users. > > > > Conrad, > > > > Should this be disabled on -stable now? > > > > -- > > John-Mark Gurney Voice: +1 415 225 > > 5579 > > > > "All that I will do, has been done, All that I have, has not." > >