lkml.org 
[lkml]   [2018]   [Jan]   [11]   [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/11/18 10:34), Petr Mladek wrote:
    [..]
    > > except that handing off a console_sem to atomic task when there
    > > is O(logbuf) > watchdog_thresh is a regression, basically...
    > > it is what it is.
    >
    > How this could be a regression? Is not the victim that handles
    > other printk's random? What protected the atomic task to
    > handle the other printks before this patch?

    the non-atomic -> atomic context console_sem transfer. we previously
    would have kept the console_sem owner to its non-atomic owner. we now
    will make sure that if printk from atomic context happens then it will
    make it to console_unlock() loop.
    emphasis on O(logbuf) > watchdog_thresh.


    - if the patch's goal is to bound (not necessarily to watchdog's threshold)
    the amount of time we spend in console_unlock(), then the patch is kinda
    overcomplicated. but no further questions in this case.

    - but if the patch's goal is to bound (to lockup threshold) the amount of
    time spent in console_unlock() in order to avoid lockups [uh, a reason],
    then the patch is rather oversimplified.


    claiming that for any given A, B, C the following is always true

    A * B < C

    where
    A is the amount of data to print in the worst case
    B the time call_console_drivers() needs to print a single
    char to all registered and enabled consoles
    C the watchdog's threshold

    is not really a step forward.

    and the "last console_sem owner prints all pending messages" rule
    is still there.


    > Or do you have a system that started to suffer from softlockups
    > with this patchset and did not do this before?
    [..]
    > Do you know about any system where this patch made the softlockup
    > deterministically or statistically more likely, please?

    I have explained many, many times why my boards die just like before.
    why would I bother collecting any numbers...

    -ss

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