Date: Thu, 20 May 2021 15:57:17 -0700 From: Conrad Meyer <cem@freebsd.org> To: Michael Gmelin <freebsd@grem.de>, "freebsd-current@freebsd.org" <freebsd-current@freebsd.org> Subject: Re: Reducing SIGINFO verbosity Message-ID: <CAG6CVpWpDYid9F0fSWyyFVuh6SuNmV4HwEBQUKTCXDGfq6KwAw@mail.gmail.com> In-Reply-To: <20210520185917.GL14975@funkthat.com> References: <20210520180155.3e23500e@bsd64.grem.de> <20210520185917.GL14975@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] 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 On Thu, May 20, 2021 at 11:59 John-Mark Gurney <jmg@funkthat.com> 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." > [-- Attachment #2 --] <div dir="auto">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).</div><div dir="auto"><br></div><div dir="auto">Conrad </div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 20, 2021 at 11:59 John-Mark Gurney <<a href="mailto:jmg@funkthat.com">jmg@funkthat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Michael Gmelin wrote this message on Thu, May 20, 2021 at 18:01 +0200:<br> > I'm leaving this here, mostly so that others (or future me) can google<br> > it up.<br> > <br> > Traditionally, CTRL-t would give a one-line output + whatever the<br> > process specific signal handler comes up with:<br> > <br> > # sleep 120 <--- hits CTRL-t<br> > load: 0.27 cmd: sleep 38162 [nanslp] 0.64r 0.00u 0.00s 0% 1780k<br> > sleep: about 119 second(s) left out of the original 120<br> > <br> > # cat <--- hits CTRL-t<br> > load: 0.02 cmd: cat 24379 [ttyin] 0.63r 0.00u 0.00s 0% 2308k<br> > <br> > <br> > On 13 I get:<br> > <br> > # sleep 120 <--- hits CTRL-t<br> > load: 0.12 cmd: sleep 3241 [nanslp] 0.52r 0.00u 0.00s 0% 2172k<br> > mi_switch+0xc1 sleepq_catch_signals+0x2e6 sleepq_timedwait_sig+0x12<br> > _sleep+0x199 kern_clock_nanosleep+0x1e1 sys_nanosleep+0x3b<br> > amd64_syscall+0x10c fast_syscall_common+0xf8 sleep: about 119<br> > second(s) left out of the original 120<br> > <br> > # cat <--- hits CTRL-t<br> > load: 0.09 cmd: cat 3240 [ttyin] 0.23r 0.00u 0.00s 0% 2300k<br> > mi_switch+0xc1 sleepq_catch_signals+0x2e6 sleepq_wait_sig+0x9<br> > _cv_wait_sig+0xe4 tty_wait+0x1c ttydisc_read+0x2ac ttydev_read+0x56<br> > devfs_read_f+0xd5 dofileread+0x81 sys_read+0xbc amd64_syscall+0x10c<br> > fast_syscall_common+0xf8 <br> > <br> > which is quite way too verbose when checking the progress of<br> > long-running processes, like cp, dd, or poudriere. Especially as CTRL-t<br> > is part of the user experience to me - I use it to interact with the<br> > machine outside of debugging software issues.<br> > <br> > Setting<br> > <br> > sysctl kern.tty_info_kstacks=0<br> > echo kern.tty_info_kstacks=0 >>/etc/sysctl.conf<br> > <br> > fixes this permanently.<br> > <br> > Apparently, this was enabled by default on purpose[0], so that people<br> > find the feature (which certainly worked ^_^), but I think it would<br> > been worth mentioning the sysctl somewhere in the release notes/errata,<br> > so that people understand how to disable it again.<br> <br> I think the original intent was to disable this on -stable or at least<br> -RELEASEs, but it looks like this didn't happen. This is VERY helpful<br> for a developer, but not as helpful for most users.<br> <br> Conrad,<br> <br> Should this be disabled on -stable now?<br> <br> -- <br> John-Mark Gurney Voice: +1 415 225 5579<br> <br> "All that I will do, has been done, All that I have, has not."<br> </blockquote></div></div>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAG6CVpWpDYid9F0fSWyyFVuh6SuNmV4HwEBQUKTCXDGfq6KwAw>