On 2020/05/15 1:26, Petr Mladek wrote:
> This does not make much sense to me. KERN_NO_CONSOLES would be another
> global flag. If you enable/disable its functionality, it would affect
> all strings with this flag (not only the ones used by OOM killer).
Are you assuming that the switch is applied o
On Thu 2020-05-14 20:23:55, Tetsuo Handa wrote:
> On 2020/05/14 17:00, Petr Mladek wrote:
> > On Wed 2020-05-13 21:59:23, Tetsuo Handa wrote:
> >> On 2020/05/13 21:19, Petr Mladek wrote:
> >>> On Wed 2020-05-13 20:24:24, Tetsuo Handa wrote:
> On 2020/05/13 19:49, Michal Hocko wrote:
> > On
On 2020/05/14 17:00, Petr Mladek wrote:
> On Wed 2020-05-13 21:59:23, Tetsuo Handa wrote:
>> On 2020/05/13 21:19, Petr Mladek wrote:
>>> On Wed 2020-05-13 20:24:24, Tetsuo Handa wrote:
On 2020/05/13 19:49, Michal Hocko wrote:
> On Wed 13-05-20 12:04:13, Petr Mladek wrote:
>> What is so
On Wed 2020-05-13 21:59:23, Tetsuo Handa wrote:
> On 2020/05/13 21:19, Petr Mladek wrote:
> > On Wed 2020-05-13 20:24:24, Tetsuo Handa wrote:
> >> On 2020/05/13 19:49, Michal Hocko wrote:
> >>> On Wed 13-05-20 12:04:13, Petr Mladek wrote:
> What is so special about OOM dump task so that it wo
On 2020/05/13 22:55, Steven Rostedt wrote:
> On Wed, 13 May 2020 20:03:53 +0900
> Tetsuo Handa wrote:
>
>> I think that basically only oops (e.g. WARN()/BUG()/panic()) messages worth
>> printing to consoles and the rest messages do not worth printing to consoles.
>> Existing KERN_$LOGLEVEL is too
On 2020/05/13 22:46, Steven Rostedt wrote:
> On Wed, 13 May 2020 20:03:53 +0900
> Tetsuo Handa wrote:
>
>> I think that basically only oops (e.g. WARN()/BUG()/panic()) messages worth
>> printing to consoles and the rest messages do not worth printing to consoles.
>> Existing KERN_$LOGLEVEL is too
On Wed, 13 May 2020 20:03:53 +0900
Tetsuo Handa wrote:
> I think that basically only oops (e.g. WARN()/BUG()/panic()) messages worth
> printing to consoles and the rest messages do not worth printing to consoles.
> Existing KERN_$LOGLEVEL is too rough-grained.
Why don't you look into having a "n
On Wed, 13 May 2020 20:03:53 +0900
Tetsuo Handa wrote:
> I think that basically only oops (e.g. WARN()/BUG()/panic()) messages worth
> printing to consoles and the rest messages do not worth printing to consoles.
> Existing KERN_$LOGLEVEL is too rough-grained.
And this statement is exactly why I
On 2020/05/13 21:19, Petr Mladek wrote:
> On Wed 2020-05-13 20:24:24, Tetsuo Handa wrote:
>> On 2020/05/13 19:49, Michal Hocko wrote:
>>> On Wed 13-05-20 12:04:13, Petr Mladek wrote:
What is so special about OOM dump task so that it would deserve such
complications?
>
>> I don't think
On Wed 2020-05-13 20:03:53, Tetsuo Handa wrote:
> On 2020/05/13 19:04, Petr Mladek wrote:
> >> What is wrong with adding NO_CONSOLES ?
> >
> > How does it differ from KERN_DEBUG? The debug messages:
> >
> > + can be disabled via sysfs
> > + might reach console when this loglevel is enabled
>
On Wed 2020-05-13 20:24:24, Tetsuo Handa wrote:
> On 2020/05/13 19:49, Michal Hocko wrote:
> > On Wed 13-05-20 12:04:13, Petr Mladek wrote:
> >> What is so special about OOM dump task so that it would deserve such
> >> complications?
> I don't think dump_tasks() is important information to be pr
On 2020/05/13 19:49, Michal Hocko wrote:
> On Wed 13-05-20 12:04:13, Petr Mladek wrote:
>> What is so special about OOM dump task so that it would deserve such
>> complications?
>
> Nothing really. Except for the potential amount of the output.
"echo t > /proc/sysrq-trigger" from userspace progr
On 2020/05/13 19:04, Petr Mladek wrote:
>> What is wrong with adding NO_CONSOLES ?
>
> How does it differ from KERN_DEBUG? The debug messages:
>
> + can be disabled via sysfs
> + might reach console when this loglevel is enabled
KERN_NO_CONSOLES is different from KERN_DEBUG in that KERN_NO_C
On Wed 13-05-20 12:04:13, Petr Mladek wrote:
> What is so special about OOM dump task so that it would deserve such
> complications?
Nothing really. Except for the potential amount of the output. But as
you've said there are two ways around that. Disable this output if you
do not need it or make
On Wed 2020-05-13 16:58:48, Tetsuo Handa wrote:
> On 2020/05/13 15:26, Sergey Senozhatsky wrote:
> > Yes, but this looks like it's the consumer of the messages who
> > decides what to filter and what not to. rsyslog, dmesg, etc.
> > will have different filtering policies. It's not like the kernel
>
On 2020/05/13 15:26, Sergey Senozhatsky wrote:
> Yes, but this looks like it's the consumer of the messages who
> decides what to filter and what not to. rsyslog, dmesg, etc.
> will have different filtering policies. It's not like the kernel
> decides what to hide and what to show. If would compare
On (20/04/30 01:35), Tetsuo Handa wrote:
> Below is the default rules for rsyslog-8.24.0-52.el7 (userspace syslog
> daemon).
> Of course administrators can modify as needed, but notice that KERN_INFO is
> saved
> to /var/log/messages but KERN_DEBUG is saved to nowhere.
>
> --
> # Log all
On 2020/05/07 14:30, Joe Perches wrote:
> I proposed awhile back making functions for pr_
> https://lore.kernel.org/lkml/1466739971-30399-1-git-send-email-...@perches.com/
Great. That will also benefit KERN_NO_CONSOLES.
>
> Maybe it's time for that and something appropriate
> like it for your ne
On Thu, 2020-05-07 at 14:13 +0900, Tetsuo Handa wrote:
> On 2020/05/07 10:02, Joe Perches wrote:
> > > > printk_get_level / printk_skip_level and the various
> > > > uses of %pV using printk_get_level
> > > >
> > >
> > > Excuse me, but what do you mean?
> > >
> > > I wish printk() accepts "logle
On 2020/05/07 10:02, Joe Perches wrote:
>>> printk_get_level / printk_skip_level and the various
>>> uses of %pV using printk_get_level
>>>
>>
>> Excuse me, but what do you mean?
>>
>> I wish printk() accepts "loglevel" argument detached from "fmt" argument
>> (e.g.
>
> I think that's a bad idea
On Thu, 2020-05-07 at 09:50 +0900, Tetsuo Handa wrote:
> On 2020/05/07 0:26, Joe Perches wrote:
> > On Wed, 2020-05-06 at 18:45 +0900, Tetsuo Handa wrote:
> > > On 2020/04/28 20:33, Tetsuo Handa wrote:
> > > > On 2020/04/27 15:21, Sergey Senozhatsky wrote:
> > > > > > KERN_NO_CONSOLES is for type o
On 2020/05/07 0:26, Joe Perches wrote:
> On Wed, 2020-05-06 at 18:45 +0900, Tetsuo Handa wrote:
>> On 2020/04/28 20:33, Tetsuo Handa wrote:
>>> On 2020/04/27 15:21, Sergey Senozhatsky wrote:
> KERN_NO_CONSOLES is for type of messages where "saved for later analysis"
> is
> important bu
On Wed, 2020-05-06 at 18:45 +0900, Tetsuo Handa wrote:
> On 2020/04/28 20:33, Tetsuo Handa wrote:
> > On 2020/04/27 15:21, Sergey Senozhatsky wrote:
> > > > KERN_NO_CONSOLES is for type of messages where "saved for later
> > > > analysis" is
> > > > important but "printed for immediate notificatio
On 2020/04/28 20:33, Tetsuo Handa wrote:
> On 2020/04/27 15:21, Sergey Senozhatsky wrote:
>>> KERN_NO_CONSOLES is for type of messages where "saved for later analysis" is
>>> important but "printed for immediate notification" is not important.
>>> In other words, KERN_NO_CONSOLES is NOT for dying m
On 2020/04/29 23:21, Michal Hocko wrote:
> I am trying to say that KERN_NO_CONSOLES resembles more a policy than a
> priority. Because I as a developer have no idea whether the message is
> good enough for console or not.
Right, KERN_NO_CONSOLES is not a priority.
> I believe we are free to chang
On Wed 29-04-20 01:23:15, Tetsuo Handa wrote:
> On 2020/04/29 0:45, Michal Hocko wrote:
> > On Tue 28-04-20 22:11:19, Tetsuo Handa wrote:
> >> Existing KERN_$LEVEL allows a user to determine whether he/she wants that
> >> message
> >> to be printed on consoles (even if it spams his/her operation d
On 2020/04/29 0:45, Michal Hocko wrote:
> On Tue 28-04-20 22:11:19, Tetsuo Handa wrote:
>> Existing KERN_$LEVEL allows a user to determine whether he/she wants that
>> message
>> to be printed on consoles (even if it spams his/her operation doing on
>> consoles), and
>> at the same time constrain
On Tue 28-04-20 22:11:19, Tetsuo Handa wrote:
> On 2020/04/28 21:18, Michal Hocko wrote:
> > On Tue 28-04-20 20:33:21, Tetsuo Handa wrote:
> >> On 2020/04/27 15:21, Sergey Senozhatsky wrote:
> KERN_NO_CONSOLES is for type of messages where "saved for later
> analysis" is
> important
On 2020/04/28 21:18, Michal Hocko wrote:
> On Tue 28-04-20 20:33:21, Tetsuo Handa wrote:
>> On 2020/04/27 15:21, Sergey Senozhatsky wrote:
KERN_NO_CONSOLES is for type of messages where "saved for later analysis"
is
important but "printed for immediate notification" is not important
On Tue 28-04-20 20:33:21, Tetsuo Handa wrote:
> On 2020/04/27 15:21, Sergey Senozhatsky wrote:
> >> KERN_NO_CONSOLES is for type of messages where "saved for later analysis"
> >> is
> >> important but "printed for immediate notification" is not important.
> >> In other words, KERN_NO_CONSOLES is N
On 2020/04/27 15:21, Sergey Senozhatsky wrote:
>> KERN_NO_CONSOLES is for type of messages where "saved for later analysis" is
>> important but "printed for immediate notification" is not important.
>> In other words, KERN_NO_CONSOLES is NOT for dying messages where "printed for
>> immediate notifi
31 matches
Mail list logo
