On (11/08/17 22:29), Steven Rostedt wrote:
> > On (11/08/17 09:29), Steven Rostedt wrote:
> > > On Wed, 8 Nov 2017 14:19:55 +0900
> > > Sergey Senozhatsky <sergey.senozhatsky.work@xxxxxxxxx> wrote:
> > >
> > > > the change goes further. I did express some of my concerns during the KS,
> > > > I'll just bring them to the list.
> > > >
> > > >
> > > > we now always shift printing from a save - scheduleable - context to
> > > > a potentially unsafe one - atomic. by example:
> > >
> > > And vice versa. We are now likely to go from a unscheduleable context
> > > to a schedule one, where before, that didn't exist.
> >
> > the existence of "and vice versa" is kinda alarming, isn't it? it's sort
> > of "yes, we can break some things, but we also can improve some things."
>
> Not really. Because the heuristic is that what calls printk will do the
> printk.
so what we are looking at
a) we take over printing. can be from safe context to unsafe context
[well, bad karma]. can be from unsafe context to a safe one. or from
safe context to another safe context... or from one unsafe context to
another unsafe context [bad karma again]. we really never know, no
one does.
lots of uncertainties - "may be X, may be Y, may be Z". a bigger
picture: we still can have the same lockup scenarios as we do
have today.
and we also bring busy loop with us, so the new console_sem
owner [regardless its current context] CPU must wait until the
current console_sem finishes its call_console_drivers(). I
mentioned it in my another email, you seemed to jump over that
part. was it irrelevant or wrong?
vs.
b) we offload to printk_kthread [safe context].
why (a) is better than (b)?
-ss
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
