lkml.org 
[lkml]   [2018]   [Jan]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup
    On (01/12/18 13:55), Petr Mladek wrote:
    [..]
    > > I'm not fixing console_unlock(), I'm fixing printk(). BTW, all my
    > > kernels are CONFIG_PREEMPT (I'm a RT guy), my mind thinks more about
    > > PREEMPT kernels than !PREEMPT ones.
    >
    > I would say that the patch improves also console_unlock() but only in
    > non-preemttive context.
    >
    > By other words, it makes console_unlock() finite in preemptible context
    > (limited by buffer size). It might still be unlimited in
    > non-preemtible context.

    could you elaborate a bit?

    [..]
    > > > reverting 6b97a20d3a7909daa06625d4440c2c52d7bf08d7 may be the right
    > > > thing after all.
    > >
    > > I would analyze that more before doing so. Because with my patch, I
    > > think we make those that can do long prints (without triggering a
    > > watchdog), the ones most likely doing the long prints.
    >
    > IMHO, it might make sense because it would help to see the messages
    > faster. But I would prefer to handle this separately because it
    > might also increase the risk of softlockups. Therefore it might
    > cause regressions.
    >
    > We should also take into account the commit 8d91f8b15361dfb438ab6
    > ("printk: do cond_resched() between lines while outputting to
    > consoles"). It has the same effect for console_lock() callers.

    I replied in another email.

    -ss

    \
     
     \ /
      Last update: 2018-01-14 23:26    [W:7.754 / U:0.024 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site