bug or freature? tty - perf: ....
Hi, up to date tumbleweed: i have a small opensuse without graphic, logging into tty1 there was a very old tumbleweed (3-4 years old, before updating this machine) behavior changed: when i use heavy load to the processor (here i pbzip2 a whole disk) i got on screen the messages (and similar messages): [1580-1618057] [ C6] perf: interrupt took to long (2503>2500), lowering kernel.perf.event_max_sample_rate to 798000 when i remember correct, the message itself is nothing to care about. BUT why is this message not (only) written inside a log file? why did this interrupt my screen output? is there something i have to configure, or why is this now on screen. on the old system it was not on screen. and i think it should not be there interrupting the output (as example if working with mc everything will be messed up) any hints? or should i open a bug report? simoN -- www.becherer.de
On Mon, Aug 26, 2024 at 3:04 PM Simon Becherer <simon@becherer.de> wrote:
Hi,
up to date tumbleweed:
i have a small opensuse without graphic, logging into tty1 there was a very old tumbleweed (3-4 years old, before updating this machine)
behavior changed:
when i use heavy load to the processor (here i pbzip2 a whole disk) i got on screen the messages (and similar messages):
[1580-1618057] [ C6] perf: interrupt took to long (2503>2500), lowering kernel.perf.event_max_sample_rate to 798000
when i remember correct, the message itself is nothing to care about.
BUT why is this message not (only) written inside a log file? why did this interrupt my screen output?
Because the kernel has a minimal log level above which everything is also printed to the console.
is there something i have to configure, or why is this now on screen.
on the old system it was not on screen. and i think it should not be there interrupting the output (as example if working with mc everything will be messed up)
It is quite possible that some defaults have changed.
any hints? or should i open a bug report?
I do not see any bug unless you can prove that the log level of this message should not appear on the console with its current settings.
Am 26.08.24 um 14:20 schrieb Andrei Borzenkov:
On Mon, Aug 26, 2024 at 3:04 PM Simon Becherer <simon@becherer.de> wrote:
is there something i have to configure, or why is this now on screen.
on the old system it was not on screen. and i think it should not be there interrupting the output (as example if working with mc everything will be messed up)
It is quite possible that some defaults have changed.
any hints? or should i open a bug report?
I do not see any bug unless you can prove that the log level of this message should not appear on the console with its current settings.
thanks for pointing me in the direction. i read a little bit inside the internet. so the new tumbleweed has: cat /proc/sys/kernel/printk 7 4 1 7 so 7 is high, i read "normal" is 4 4 1 7 at the moment i am not on an old enough system to check what it was before. 2 questions: when i pass a commandline loglevel=4 parameter to the kernel, i guess that all the messages at boot will also be affected. is this correct? -> this would not be what i like. when i like to have it after logging in, is the .bashrc file the correct place also for tty ? thanks in advance, simoN -- www.becherer.de
On Mon, Aug 26, 2024 at 5:13 PM Simon Becherer <simon@becherer.de> wrote:
Am 26.08.24 um 14:20 schrieb Andrei Borzenkov:
On Mon, Aug 26, 2024 at 3:04 PM Simon Becherer <simon@becherer.de> wrote:
is there something i have to configure, or why is this now on screen.
on the old system it was not on screen. and i think it should not be there interrupting the output (as example if working with mc everything will be messed up)
It is quite possible that some defaults have changed.
any hints? or should i open a bug report?
I do not see any bug unless you can prove that the log level of this message should not appear on the console with its current settings.
thanks for pointing me in the direction.
i read a little bit inside the internet.
so the new tumbleweed has:
cat /proc/sys/kernel/printk 7 4 1 7
CONFIG_CONSOLE_LOGLEVEL_DEFAULT=7 CONFIG_CONSOLE_LOGLEVEL_QUIET=4 So, without "quiet" on the kernel command line you get 7.
so 7 is high, i read "normal" is 4 4 1 7 at the moment i am not on an old enough system to check what it was before.
2 questions: when i pass a commandline loglevel=4 parameter to the kernel, i guess that all the messages at boot will also be affected. is this correct?
I did not use it myself, but from the documentation it should work unless overridden later.
-> this would not be what i like.
when i like to have it after logging in, is the .bashrc file the correct place also for tty ?
This is kernel.printk sysctl. Just add it to /etc/sysctld. In the past it was also set by tools like klogd. Not sure if something like this is still used (as the value is kernel default, probably, not). In general, any program may mess with it.
Hi, Am 26.08.24 um 16:30 schrieb Andrei Borzenkov:
On Mon, Aug 26, 2024 at 5:13 PM Simon Becherer <simon@becherer.de> wrote:
Am 26.08.24 um 14:20 schrieb Andrei Borzenkov:
On Mon, Aug 26, 2024 at 3:04 PM Simon Becherer <simon@becherer.de> wrote:
is there something i have to configure, or why is this now on screen.
on the old system it was not on screen. and i think it should not be there interrupting the output (as example if working with mc everything will be messed up)
It is quite possible that some defaults have changed.
any hints? or should i open a bug report?
I do not see any bug unless you can prove that the log level of this message should not appear on the console with its current settings.
thanks for pointing me in the direction.
i read a little bit inside the internet.
so the new tumbleweed has:
cat /proc/sys/kernel/printk 7 4 1 7
CONFIG_CONSOLE_LOGLEVEL_DEFAULT=7 CONFIG_CONSOLE_LOGLEVEL_QUIET=4
So, without "quiet" on the kernel command line you get 7.
so 7 is high, i read "normal" is 4 4 1 7 at the moment i am not on an old enough system to check what it was before.
2 questions: when i pass a commandline loglevel=4 parameter to the kernel, i guess that all the messages at boot will also be affected. is this correct?
I did not use it myself, but from the documentation it should work unless overridden later.
-> this would not be what i like.
when i like to have it after logging in, is the .bashrc file the correct place also for tty ?
This is kernel.printk sysctl. Just add it to /etc/sysctld.
In the past it was also set by tools like klogd. Not sure if something like this is still used (as the value is kernel default, probably, not). In general, any program may mess with it.
you are right, it has changed sometimes in past. the tumbleweed system propably from 2018, i updated sometimes in this year has had: 1 4 1 7 i will try at the weekend to generate a file inside /etc/sysctl.d simoN -- www.becherer.de
Hello, In the Message; Subject : Re: bug or freature? tty - perf: .... Message-ID : <70269f28-f049-41ad-a48e-40af58c9d727@becherer.de> Date & Time: Tue, 27 Aug 2024 07:30:35 +0200 [SB] == Simon Becherer <simon@becherer.de> has written: SB> [1 <multipart/mixed (7bit)>] SB> [1.1 <text/plain; UTF-8 (base64)>] SB> Hi, SB> Am 26.08.24 um 16:30 schrieb Andrei Borzenkov: AB> > This is kernel.printk sysctl. Just add it to /etc/sysctld. AB> > In the past it was also set by tools like klogd. Not sure if something AB> > like this is still used (as the value is kernel default, probably, AB> > not). In general, any program may mess with it. SB> you are right, it has changed sometimes in past. SB> the tumbleweed system propably from 2018, i updated sometimes in SB> this year has had: SB> 1 4 1 7 SB> i will try at the weekend to generate a file inside /etc/sysctl.d You can now check the current settings; $ cat /proc/sys/kernel/perf_event_max_sample_rate then, write the obtained value VALUE. # echo kernel.perf_event_max_sample_rate=VALUE >> /etc/sysctl.d/local.conf My current VALUE at Tumbleweed is 61800. Best Regards. --- ┏━━┓彡 Masaru Nomiya mail-to: nomiya @ lake.dti.ne.jp ┃＼／彡 ┗━━┛ "To hire for skills, firms will need to implement robust and intentional changes in their hiring practices ― and change is hard." -- Employers don’t practice what they preach on skills-based hiring --
participants (3)
-
Andrei Borzenkov -
Masaru Nomiya -
Simon Becherer