lkml.org 
[lkml]   [2017]   [Nov]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 2/2] Subject: printk: Don't trap random context in infinite log_buf flush
    Hello,

    On Wed, Nov 08, 2017 at 02:29:35PM +0900, Sergey Senozhatsky wrote:
    > > The following is a completely untested patch to show how we can put
    > > the console in full sync mode, just the general idea. I'm a bit
    > > skeptical we really wanna do this given that we already (with or
    > > without the patch) stay sync for most of these events due to the way
    > > we go async, but, yeah, if we wanna do that, we can do that.
    >
    > we've been going in a slightly different direction in printk-kthread.
    >
    > we keep printk sync by default [as opposed to previous "immediately
    > offload" approach]. people asked for it, some people demanded it. we
    > offload to printk-kthread only when we detect that this particular
    > task on this particular CPU has been doing printing (without rescheduling)
    > for 1/2 of watchdog threshold value. IOW, if we see that we are heading
    > towards the lockup limit then we offload. otherwise - we let it loop in
    > console_unlock().

    FWIW, I'm still a bit skeptical whether that's the right direction.
    People asking for it doesn't indicate that the flipside isn't worse.
    Hmm... I think my impression is mostly from the fact that throughout
    the years I can only count few times where loss of printk messages was
    an actual issue. The system getting slowed down / locking up from
    printk message deluge was *far* more prevalent.

    Thanks.

    --
    tejun

    \
     
     \ /
      Last update: 2017-11-08 21:12    [W:5.779 / U:0.500 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site