Messages in this thread | | | Date | Tue, 19 Dec 2017 15:31:47 +0100 | From | Michal Hocko <> | Subject | Re: [RFC][PATCHv6 00/12] printk: introduce printing kernel thread |
| |
On Tue 19-12-17 10:24:55, Sergey Senozhatsky wrote: > On (12/18/17 20:08), Steven Rostedt wrote: > > > ... do you guys read my emails? which part of the traces I have provided > > > suggests that there is any improvement? > > > > The traces I've seen from you were from non-realistic scenarios. > > But I have hit issues with printk()s happening that cause one CPU to do all > > the work, where my patch would fix that. Those are the scenarios I'm > > talking about. > > any hints about what makes your scenario more realistic than mine?
Well, Tetsuo had some semi-realistic scenario where alloc stall messages managed to stall other printk callers (namely oom handler). I am saying sem-realistic because he is testing OOM throughput with an unrealistic workload which itself is not very real on production systems. The essential thing here is that many processes might be in the allocation path and any printk there could just swamp some unrelated printk caller and cause hard to debug problems. Steven's patch should address that with a relatively simple lock handover. I was pessimistic this would work sufficiently well but it survived Tetsuo's testing IIRC so it sounds good enough to me. -- Michal Hocko SUSE Labs
| |