Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup

[Steven Rostedt]

On Wed, 10 Jan 2018 11:34:51 -0800
Tejun Heo <tj@xxxxxxxxxx> wrote:

> > Right now my focus is an incremental approach. I'm not trying to solve
> > all issues that printk has. I've focused on a single issue, and that is
> > that printk is unbounded. Coming from a Real Time background, I find
> > that is a big problem. I hate unbounded algorithms. I looked at this
> > and found a way to make printk have a max bounded time it can print.
> > Sure, it can be more than what you want, but it is a constant time,
> > that can be measured. Hence, it is an O(1) solution.  
> 
> It is bound iff there are contexts which can bounce the flushing role
> among them, right?

No, not at all. The printk can only print what's in the buffer. The
buffer can only get more to print if another printk occurs. If that
happens, that other printk takes over. Thus, any single printk can
print at most one buffer full. Which is bounded to the size of the
buffer.

Yes, there can be the case that printks are added via an interrupt, but
then again, it's an issue that a single CPU. And printks from interrupt
context should be considered critical, part of the ASAP category. If
they are not critical, then they shouldn't be doing printks. That may
be a place were we can add a "printk_delay", for things like non
critical printks in interrupt context, that can trigger offloading?

> 
> > Now, if there is still issues with printk, there may be cases where
> > offloading makes sense. I don't see why we should stop my solution
> > because we are not addressing these other issues where offloading may
> > make sense. My solution is simple, and does not impact other solutions.
> > It may even show that other solutions are not needed. But that's a good
> > thing.
> > 
> > I'm not against an offloading solution if it can solve issues without
> > impacting the other printk use cases. I'm currently only focusing on
> > this solution which you are fighting me against.  
> 
> Oh yeah, sure.  It might actually be pretty simple to combine into
> your solution.  For example, can't we just always make sure that
> there's at least one sleepable context which participates in your
> pingpongs, which only kicks in when a particular context is trapped
> too long?

The solution can be extended to that if the need exists, yes.

-- Steve