On 2018/10/23 17:21, Petr Mladek wrote:
> On Fri 2018-10-19 09:18:16, Tetsuo Handa wrote:
>> I assumed we calculate the average dynamically, for the amount of
>> messages printed by an OOM event is highly unstable (depends on
>> hardware configuration such as number of nodes, number of zones,
>> an
[I strongly suspect this whole email thread went way out of scope of the
issue really deserves]
I didn't want to participate any further but let me clarify one thing
because I can see how the discussion could generate some confusion.
On Tue 23-10-18 10:37:38, Petr Mladek wrote:
[...]
> My unders
On Fri 2018-10-19 19:35:53, Tetsuo Handa wrote:
> On 2018/10/19 8:54, Sergey Senozhatsky wrote:
> > On (10/18/18 20:58), Tetsuo Handa wrote:
> >> That boils down to a "user interaction" problem.
> >> Not limiting
> >>
> >> "%s invoked oom-killer: gfp_mask=%#x(%pGg), nodemask=%*pbl, order=%d,
> >
On Fri 2018-10-19 09:18:16, Tetsuo Handa wrote:
> Petr Mladek wrote:
> > This looks very complex and I see even more problems:
> >
> > + You would need to update the rate limit intervals when
> > new console is attached. Note that the ratelimits might
> > get initialized early during boo
On (10/19/18 19:35), Tetsuo Handa wrote:
> >
> > OK, that's a fair point. There was a patch from FB, which would allow us
> > to set a log_level on per-console basis. So the noise goes to heav^W net
> > console; only critical stuff goes to the serial console (if I recall it
> > correctly). I'm not
On 2018/10/19 8:54, Sergey Senozhatsky wrote:
> On (10/18/18 20:58), Tetsuo Handa wrote:
>>>
>>> A knob might do.
>>> As well as /proc/sys/kernel/printk tweaks, probably. One can even add
>>> echo "a b c d" > /proc/sys/kernel/printk to .bashrc and adjust printk
>>> console levels on login and rollb
Petr Mladek wrote:
> This looks very complex and I see even more problems:
>
> + You would need to update the rate limit intervals when
> new console is attached. Note that the ratelimits might
> get initialized early during boot. It might be solvable
> but ...
>
> + You might nee
On (10/18/18 20:58), Tetsuo Handa wrote:
> >
> > A knob might do.
> > As well as /proc/sys/kernel/printk tweaks, probably. One can even add
> > echo "a b c d" > /proc/sys/kernel/printk to .bashrc and adjust printk
> > console levels on login and rollback to old values in .bash_logout
> > May be.
>
On Thu 2018-10-18 13:27:39, Sergey Senozhatsky wrote:
> On (10/18/18 11:46), Tetsuo Handa wrote:
> > Sergey Senozhatsky wrote:
> > >
> > > int printk_ratelimit_interval(void)
> > > {
> > >int ret = DEFAULT_RATELIMIT_INTERVAL;
> > >struct tty_driver *driver = NULL;
> > >spee
On 2018/10/18 17:13, Sergey Senozhatsky wrote:
> On (10/18/18 09:56), Michal Hocko wrote:
>> On Thu 18-10-18 15:10:18, Sergey Senozhatsky wrote:
>> [...]
>>> and let's hear from MM people what they can suggest.
>>>
>>> Michal, Andrew, Johannes, any thoughts?
>>
>> I have already stated my position.
On Thu 18-10-18 19:37:18, Tetsuo Handa wrote:
> On 2018/10/18 15:55, Michal Hocko wrote:
> > On Thu 18-10-18 11:46:50, Tetsuo Handa wrote:
> >> This is essentially a ratelimit approach, roughly equivalent with:
> >>
> >> static DEFINE_RATELIMIT_STATE(oom_no_victim_rs, 60 * HZ, 1);
> >> oom_no_v
On 2018/10/18 15:55, Michal Hocko wrote:
> On Thu 18-10-18 11:46:50, Tetsuo Handa wrote:
>> This is essentially a ratelimit approach, roughly equivalent with:
>>
>> static DEFINE_RATELIMIT_STATE(oom_no_victim_rs, 60 * HZ, 1);
>> oom_no_victim_rs.flags |= RATELIMIT_MSG_ON_RELEASE;
>>
>> if (__
On (10/18/18 09:56), Michal Hocko wrote:
> On Thu 18-10-18 15:10:18, Sergey Senozhatsky wrote:
> [...]
> > and let's hear from MM people what they can suggest.
> >
> > Michal, Andrew, Johannes, any thoughts?
>
> I have already stated my position. Let's not reinvent the wheel and use
> the standar
On Thu 18-10-18 15:10:18, Sergey Senozhatsky wrote:
[...]
> and let's hear from MM people what they can suggest.
>
> Michal, Andrew, Johannes, any thoughts?
I have already stated my position. Let's not reinvent the wheel and use
the standard printk throttling. If there are cases where oom reports
On Thu 18-10-18 11:46:50, Tetsuo Handa wrote:
> Sergey Senozhatsky wrote:
> > On (10/17/18 12:28), Michal Hocko wrote:
> > > > Michal proposed ratelimiting dump_header() [2]. But I don't think that
> > > > that patch is appropriate because that patch does not ratelimit
> > > >
> > > > "%s invoke
On (10/18/18 14:26), Tetsuo Handa wrote:
> Sergey Senozhatsky wrote:
> > To my personal taste, "baud rate of registered and enabled consoles"
> > approach is drastically more relevant than hard coded 10 * HZ or
> > 60 * HZ magic numbers... But not in the form of that "min baud rate"
> > brain fart,
Sergey Senozhatsky wrote:
> To my personal taste, "baud rate of registered and enabled consoles"
> approach is drastically more relevant than hard coded 10 * HZ or
> 60 * HZ magic numbers... But not in the form of that "min baud rate"
> brain fart, which I have posted.
I'm saying that my 60 * HZ i
On (10/18/18 11:46), Tetsuo Handa wrote:
> Sergey Senozhatsky wrote:
> >
> > int printk_ratelimit_interval(void)
> > {
> >int ret = DEFAULT_RATELIMIT_INTERVAL;
> >struct tty_driver *driver = NULL;
> >speed_t min_baud = MAX_INT;
> >
> >console_lock();
> >for
Sergey Senozhatsky wrote:
> On (10/17/18 12:28), Michal Hocko wrote:
> > > Michal proposed ratelimiting dump_header() [2]. But I don't think that
> > > that patch is appropriate because that patch does not ratelimit
> > >
> > > "%s invoked oom-killer: gfp_mask=%#x(%pGg), nodemask=%*pbl, order=%d
On Wed 17-10-18 20:17:24, Sergey Senozhatsky wrote:
> On (10/17/18 12:28), Michal Hocko wrote:
> > > Michal proposed ratelimiting dump_header() [2]. But I don't think that
> > > that patch is appropriate because that patch does not ratelimit
> > >
> > > "%s invoked oom-killer: gfp_mask=%#x(%pGg)
On (10/17/18 12:28), Michal Hocko wrote:
> > Michal proposed ratelimiting dump_header() [2]. But I don't think that
> > that patch is appropriate because that patch does not ratelimit
> >
> > "%s invoked oom-killer: gfp_mask=%#x(%pGg), nodemask=%*pbl, order=%d,
> > oom_score_adj=%hd\n"
> > "O
On Wed 17-10-18 19:06:22, Tetsuo Handa wrote:
> syzbot is hitting RCU stall at shmem_fault() [1].
> This is because memcg-OOM events with no eligible task (current thread
> is marked as OOM-unkillable) continued calling dump_header() from
> out_of_memory() enabled by commit 3100dab2aa09dc6e ("mm: m
22 matches
Mail list logo
