From nobody Thu May 20 22:57:17 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 416E78C050B for ; Thu, 20 May 2021 22:57:31 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-ot1-f41.google.com (mail-ot1-f41.google.com [209.85.210.41]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FmQ9k3vWtz3j00 for ; Thu, 20 May 2021 22:57:30 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-ot1-f41.google.com with SMTP id i14-20020a9d624e0000b029033683c71999so5176540otk.5 for ; Thu, 20 May 2021 15:57:30 -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:references:in-reply-to:reply-to :from:date:message-id:subject:to; bh=klGEkZaChWS0ARD3vEJrNvgvy5Xx6vSQdcoyzy61a9w=; b=uafcvlHe8OaYNQXy62AHSYPQl7tiqK17DnuHxY7IUlq2jeIrGrMw02wlTd1JgTZOmY C4187T5o8pnugEuIRX+CFRafX7wcIZzGM49WsVLShLRMUqxiqSTMNrJd4s2Xt3o5+baY 5IQ9j9JHM6VdnJPmzuiX+5KJHqH1kUQ96MCP66J5rvoQAKHh/vvGfdrkxnFBBamiom72 a95/a4+j5rACyC6NPBRCwQ2qOxTtBJyEjGZiV4wlWAExOpom0Z/96cgy48OYY2T9GF+w kNhux/z2z4Cr9yByagcIi7rLRoJEfB8jcNJmDmzbGksqMt/MoC8ZLBVtjJPqnltEHk83 ot6w== X-Gm-Message-State: AOAM532zsgNoF3mYIeTOWHQIxCAF+WG/qOGujmTWoTeZJ2TXMHZ3DXaG zX3orH/RwIDrCv8MCsZvI0UpKFk1VAA= X-Google-Smtp-Source: ABdhPJxQqT2d07eoIhgKgeGC6eYIsxMFRRVzga+hnEg7Xh0L0Cjgj5fJF4E/qqALsafcgHRXm2+Mhw== X-Received: by 2002:a9d:8c2:: with SMTP id 60mr5739485otf.217.1621551449081; Thu, 20 May 2021 15:57:29 -0700 (PDT) Received: from mail-ot1-f54.google.com (mail-ot1-f54.google.com. [209.85.210.54]) by smtp.gmail.com with ESMTPSA id y205sm815574oie.58.2021.05.20.15.57.28 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 20 May 2021 15:57:28 -0700 (PDT) Received: by mail-ot1-f54.google.com with SMTP id r26-20020a056830121ab02902a5ff1c9b81so16344398otp.11 for ; Thu, 20 May 2021 15:57:28 -0700 (PDT) X-Received: by 2002:a05:6830:cd:: with SMTP id x13mr5614263oto.299.1621551448604; Thu, 20 May 2021 15:57:28 -0700 (PDT) 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 References: <20210520180155.3e23500e@bsd64.grem.de> <20210520185917.GL14975@funkthat.com> In-Reply-To: <20210520185917.GL14975@funkthat.com> Reply-To: cem@freebsd.org From: Conrad Meyer Date: Thu, 20 May 2021 15:57:17 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Reducing SIGINFO verbosity To: Michael Gmelin , "freebsd-current@freebsd.org" Content-Type: multipart/alternative; boundary="00000000000014430805c2cadeab" X-Rspamd-Queue-Id: 4FmQ9k3vWtz3j00 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of csecem@gmail.com designates 209.85.210.41 as permitted sender) smtp.mailfrom=csecem@gmail.com X-Spamd-Result: default: False [-1.06 / 15.00]; HAS_REPLYTO(0.00)[cem@freebsd.org]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[209.85.210.41:from]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; FORGED_SENDER(0.30)[cem@freebsd.org,csecem@gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; R_DKIM_NA(0.00)[]; TAGGED_FROM(0.00)[]; FROM_NEQ_ENVFROM(0.00)[cem@freebsd.org,csecem@gmail.com]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[209.85.210.41:from]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; NEURAL_SPAM_MEDIUM(0.94)[0.941]; SPAMHAUS_ZRD(0.00)[209.85.210.41:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[209.85.210.41:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] --00000000000014430805c2cadeab Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable No, I don=E2=80=99t think there=E2=80=99s any reason to default it differen= tly on stable vs current. I think it=E2=80=99s useful (and I prefer the more verbose form, w= hich isn=E2=80=99t the default). Conrad 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=3D0 > > echo kern.tty_info_kstacks=3D0 >>/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." > --00000000000014430805c2cadeab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
No, I don=E2=80=99t think there=E2=80=99s any reason to d= efault it differently on stable vs current. I think it=E2=80=99s useful (an= d I prefer the more verbose form, which isn=E2=80=99t the default).

Conrad=C2=A0

On Thu, May 20= , 2021 at 11:59 John-Mark Gurney <jm= g@funkthat.com> wrote:
Micha= el 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 go= ogle
> it up.
>
> Traditionally, CTRL-t would give a one-line output + whatever the
> process specific signal handler comes up with:
>
>=C2=A0 =C2=A0# sleep 120 <--- hits CTRL-t
>=C2=A0 =C2=A0load: 0.27=C2=A0 cmd: sleep 38162 [nanslp] 0.64r 0.00u 0.0= 0s 0% 1780k
>=C2=A0 =C2=A0sleep: about 119 second(s) left out of the original 120 >
>=C2=A0 =C2=A0# cat <--- hits CTRL-t
>=C2=A0 =C2=A0load: 0.02=C2=A0 cmd: cat 24379 [ttyin] 0.63r 0.00u 0.00s = 0% 2308k
>
>=C2=A0 =C2=A0
> On 13 I get:
>
>=C2=A0 =C2=A0# sleep 120 <--- hits CTRL-t
>=C2=A0 =C2=A0load: 0.12=C2=A0 cmd: sleep 3241 [nanslp] 0.52r 0.00u 0.00= s 0% 2172k
>=C2=A0 =C2=A0mi_switch+0xc1 sleepq_catch_signals+0x2e6 sleepq_timedwait= _sig+0x12
>=C2=A0 =C2=A0_sleep+0x199 kern_clock_nanosleep+0x1e1 sys_nanosleep+0x3b=
>=C2=A0 =C2=A0amd64_syscall+0x10c fast_syscall_common+0xf8 sleep: about = 119
>=C2=A0 =C2=A0second(s) left out of the original 120
>
>=C2=A0 =C2=A0# cat <--- hits CTRL-t
>=C2=A0 =C2=A0load: 0.09=C2=A0 cmd: cat 3240 [ttyin] 0.23r 0.00u 0.00s 0= % 2300k
>=C2=A0 =C2=A0mi_switch+0xc1 sleepq_catch_signals+0x2e6 sleepq_wait_sig+= 0x9
>=C2=A0 =C2=A0_cv_wait_sig+0xe4 tty_wait+0x1c ttydisc_read+0x2ac ttydev_= read+0x56
>=C2=A0 =C2=A0devfs_read_f+0xd5 dofileread+0x81 sys_read+0xbc amd64_sysc= all+0x10c
>=C2=A0 =C2=A0fast_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
>
>=C2=A0 =C2=A0sysctl kern.tty_info_kstacks=3D0
>=C2=A0 =C2=A0echo kern.tty_info_kstacks=3D0 >>/etc/sysctl.conf >
> fixes this permanently.
>
> Apparently, this was enabled by default on purpose[0], so that people<= br> > 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.=C2=A0 This is VERY hel= pful
for a developer, but not as helpful for most users.

Conrad,

Should this be disabled on -stable now?

--
=C2=A0 John-Mark Gurney=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Voice: +1 415 225 5579=

=C2=A0 =C2=A0 =C2=A0"All that I will do, has been done, All that I hav= e, has not."
--00000000000014430805c2cadeab--