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

Groups > linux.kernel > #1314853

Re: [RFC][PATCH -next 2/2] printk: set may_schedule for some of console_trylock callers

Show all headers | View raw

On Thu 2016-01-21 14:51:46, Sergey Senozhatsky wrote:
> On (01/21/16 10:25), Sergey Senozhatsky wrote:
> [..]
> > > First, the message "This stops the holder of console_sem just where we
> > > want him" is suspitious.
> > 
> > this comment is irrelevant, as of today. it was, a long time ago, because
> > the entire thing was a bit different (linux-2.4.21 kernel/printk.c)
> > 
> >         /* This stops the holder of console_sem just where we want him */
> >         spin_lock_irqsave(&logbuf_lock, flags);
> > 
> > logbuf_lock does stop the holder, local_irq_save() does not, you are right.
> 
> I meant 'irrelevant on its current place'.

Thanks a lot for confirmation.

> [..]
> > > As a result, I think that we do not need the extra checks
> > > for the save context in printk(). IMHO, it is safe to remove
> > > all the console_may_schedule stuff and also remove the extra
> > > preempt_disable/preempt_enable() in vprintk_emit().
> > > 
> > > Or did I miss anything?
> > 
> > hm... I suspect the reason we have console_may_schedule is
> > console_conditional_schedule() - console_sem owner may want
> > to have an internal logic to re-schedule [fwiw], while still
> > holding the console_sem. tty/vt/vt.c or video/console/fbcon.c
> > for example. (in 2.4 kernel: video/fbcon.c and char/console.c).
> > 
> > cond_resched() helps in console_unlock(); console_conditional_schedule()
> > is called after console_lock() and _before_ console_unlock()....
> 
> for CONFIG_PREEMPT_COUNT kernel we can do something like
> 
> +void __sched console_conditional_schedule(void)
> +{
> +       if (!oops_in_progress && preemptible() && !rcu_preempt_depth())
> +               cond_resched();
> +}
> 
> and in console_unlock()
> 
> -               if (do_cond_resched)
> -                       cond_resched();
> +               console_conditional_schedule();
>
>
> but for !CONFIG_PREEMPT_COUNT we can't. because of currently held spin_locks/etc
> that we don't know about.

Ah, I was not aware that we did not have information about preemption
without PREEMPT_COUNT.


> `console_may_schedule' carries a bit of important information for
> console_conditional_schedule() caller. if it has acquired console_sem
> via console_lock() - then it can schedule, if via console_trylock() - it cannot.
> 
> the last `if via console_trylock() - it cannot' rule is not always true,
> we clearly can have printk()->console_unlock() from non-atomic contexts
> (if we know that its non-atomic, which is not the case with !PREEMPT_COUNT).

By other words, we could automatically detect save context for
cond_resched() only if PREEMPT_COUNT is enabled. Otherwise, we need to
keep the current logic (heuristic). Do I get it correctly, please?

I would personally wait a bit for Jack's async console printing.
It will call console only if oops_in_progress is set. It means that
this partial optimization won't be needed at all.

The other (first) patch still makes sense in the simplified form.


Best Regards,
Petr

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: [RFC][PATCH -next 2/2] printk: set may_schedule for some of  console_trylock callers Sergey Senozhatsky <sergey.senozhatsky@gmail.com> - 2016-01-17 15:20 +0100
  Re: [RFC][PATCH -next 2/2] printk: set may_schedule for some of  console_trylock callers Sergey Senozhatsky <sergey.senozhatsky@gmail.com> - 2016-01-17 15:30 +0100
    Re: [RFC][PATCH -next 2/2] printk: set may_schedule for some of  console_trylock callers Petr Mladek <pmladek@suse.com> - 2016-01-18 17:20 +0100
      Re: [RFC][PATCH -next 2/2] printk: set may_schedule for some of  console_trylock callers Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-01-19 02:20 +0100
        Re: [RFC][PATCH -next 2/2] printk: set may_schedule for some of  console_trylock callers Petr Mladek <pmladek@suse.com> - 2016-01-19 16:20 +0100
          Re: [RFC][PATCH -next 2/2] printk: set may_schedule for some of  console_trylock callers Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-01-20 05:00 +0100
            Re: [RFC][PATCH -next 2/2] printk: set may_schedule for some of  console_trylock callers Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-01-20 13:00 +0100
              Re: [RFC][PATCH -next 2/2] printk: set may_schedule for some of  console_trylock callers Petr Mladek <pmladek@suse.com> - 2016-01-20 13:40 +0100
            Re: [RFC][PATCH -next 2/2] printk: set may_schedule for some of  console_trylock callers Petr Mladek <pmladek@suse.com> - 2016-01-20 13:40 +0100
              Re: [RFC][PATCH -next 2/2] printk: set may_schedule for some of  console_trylock callers Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-01-21 02:30 +0100
                Re: [RFC][PATCH -next 2/2] printk: set may_schedule for some of  console_trylock callers Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-01-21 07:00 +0100
                Re: [RFC][PATCH -next 2/2] printk: set may_schedule for some of  console_trylock callers Petr Mladek <pmladek@suse.com> - 2016-01-22 10:50 +0100
                Re: [RFC][PATCH -next 2/2] printk: set may_schedule for some of  console_trylock callers Sergey Senozhatsky <sergey.senozhatsky@gmail.com> - 2016-01-23 05:50 +0100

csiph-web