Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1676669 > unrolled thread

Re: [RFC][PATCHv4 0/7] printk: introduce printing kernel threads

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [RFC][PATCHv4 0/7] printk: introduce printing kernel threads Petr Mladek <pmladek@suse.com> - 2017-06-28 15:50 +0200
    Re: [RFC][PATCHv4 0/7] printk: introduce printing kernel threads Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2017-06-29 10:00 +0200
      Re: [RFC][PATCHv4 0/7] printk: introduce printing kernel threads Petr Mladek <pmladek@suse.com> - 2017-06-30 14:20 +0200
        Re: [RFC][PATCHv4 0/7] printk: introduce printing kernel threads Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2017-06-30 14:50 +0200

#1676669 — Re: [RFC][PATCHv4 0/7] printk: introduce printing kernel threads

On Thu 2017-06-08 17:18:29, Sergey Senozhatsky wrote:
> we still don't have guarantees that printk_kthread will be scheduled on
> a CPU that can run it immediately or anytime in the future, but not too
> late. printk_kthread can even be scheduled on the CPU that has requested
> offloading in the first place (am I wrong on this assumption?). which means
> that printk_kthread may not be able to take over (think of a printk() dump
> from IRQ context). that's the reason why I additionally want to
> console_trylock() for PRINTK_PENDING_PRINTK_OFFLOAD.
> 
> 
> but console_trylock() is not really reliable. not at all. it's a very fast
> one shot action that most likely will see console_sem still being locked
> but the CPU that has requested offloading. I want something to wait on
> console_sem, that's reliably. and we need woken up (running) printk_kthread
> for that.
> 
> 
> may be... we can set CPU affinity on printk_kthread before we wake it up?
> place into rq of the CPU that is processing PRINTK_PENDING_PRINTK_OFFLOAD?
> 
> or allow it on any CPU but the currently printing CPU.
> 
> or have per-CPU printk kthreads and wake_up processes that are already
> bound to specific rq-s. (I know it's ugly, to put it politely. I'm just
> trying different solutions/approaches).

My head is whirling when thinking about all the per-CPU stuff. It is
looking for escape. The way is to keep it as simple as possible.

After all, we should need all this only when there is a flood of
messages. Otherwise, the messages should be handled immediately
within atomic_print_limit.

If there is a flood of messages and we do not sleep inside
console_unlock(), there should always be a new volunteer that
would continue with console flushing.

It the flood stops and the system works, we should have enough
time to recover. If the system stops working during the flood
then I am afraid that even the per-CPU kthreads would not help
much.

Does this makes sense? Or did my head hide some important aspect
again?

Best Regards,
Petr

[toc] | [next] | [standalone]

#1677503

On (06/28/17 15:42), Petr Mladek wrote:
[..]
> My head is whirling when thinking about all the per-CPU stuff. It is
> looking for escape. The way is to keep it as simple as possible.
> 
> After all, we should need all this only when there is a flood of
> messages. Otherwise, the messages should be handled immediately
> within atomic_print_limit.
> 
> If there is a flood of messages and we do not sleep inside
> console_unlock(), there should always be a new volunteer that
> would continue with console flushing.
> 
> It the flood stops and the system works, we should have enough
> time to recover. If the system stops working during the flood
> then I am afraid that even the per-CPU kthreads would not help
> much.
> 
> Does this makes sense? Or did my head hide some important aspect
> again?

yeah, I agree and understand that per-CPU printk kthreads
is a bit... too much.

it was just a quick idea and I just gave it a try. but there
are some potential takeaways from the series (not sure if you
looked at the last patches of the series).

with per-CPU kthreads we easily

1) can be quite flexible
   there can be only certain CPUs that will take over printing duty.
   so if you system has, say, IRQ affinity set up or anything else
   that is critical, you can forbid printk offloading to those CPUs.
   so "important" CPUs will not print out more than atomic_limit chars,
   the rest of the job will be handled by "less important" CPUs.

   * this can be achieved with a single printk kthread.
     but still, that's something I haven't thought about before this
     series.


2) can offload printing to other CPUs from vprintk_emit()
   and avoid any of scheduler->timekeeping->etc. paths. which will
   replace printk_deferred().

   * this can be achieved with a single printk kthread as well.
   ** at the same time this kills the direct print out guarantees.


there was something else. but I forgot what was it...

	-ss

[toc] | [prev] | [next] | [standalone]

#1678755

On Thu 2017-06-29 16:56:30, Sergey Senozhatsky wrote:
> yeah, I agree and understand that per-CPU printk kthreads
> is a bit... too much.
> 
> it was just a quick idea and I just gave it a try. but there
> are some potential takeaways from the series (not sure if you
> looked at the last patches of the series).
> 
> with per-CPU kthreads we easily
> 
> 1) can be quite flexible
>    there can be only certain CPUs that will take over printing duty.
>    so if you system has, say, IRQ affinity set up or anything else
>    that is critical, you can forbid printk offloading to those CPUs.
>    so "important" CPUs will not print out more than atomic_limit chars,
>    the rest of the job will be handled by "less important" CPUs.
> 
>    * this can be achieved with a single printk kthread.
>      but still, that's something I haven't thought about before this
>      series.

Sounds interesting. Well, I would prefer to leave this for
further optimization. It is a completely new area and it might
open another can of worms.

> 2) can offload printing to other CPUs from vprintk_emit()
>    and avoid any of scheduler->timekeeping->etc. paths. which will
>    replace printk_deferred().

I probably miss something. There is still called wake_up_process()
in this patchset and we could not do this in some scheduler and
timekeeping paths. Also we must not take the console_lock() in
these paths because it calls wake_up_process() as well. But
we want to flush few lines when possible.

Best Regards,
Petr

[toc] | [prev] | [next] | [standalone]

#1678775

On (06/30/17 14:11), Petr Mladek wrote:
> > 2) can offload printing to other CPUs from vprintk_emit()
> >    and avoid any of scheduler->timekeeping->etc. paths. which will
> >    replace printk_deferred().
> 
> I probably miss something. There is still called wake_up_process()
> in this patchset and we could not do this in some scheduler and
> timekeeping paths. Also we must not take the console_lock() in
> these paths because it calls wake_up_process() as well. But
> we want to flush few lines when possible.

yes. but we could call wake_up_process() on !this_cpu.
so we wouldn't take this_cpu ->rq lock and so on.

	CPU1

	vprintk_emit()
		wake_up_process(printk_kthread on CPU2);

	-ss

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web