Hello,
On (04/06/16 10:27), Jan Kara wrote:
[..]
> > Well, it's good that we have this.
> >
> > It would be better if it was runtime-controllable - changing boot
> > parameters is a bit of a pain. In fact with this approach, your
> > zillions-of-scsi-disks scenario becomes less problematic: do the async
> > offloading during the boot process then switch back to the more
> > reliable sync printing late in boot.
>
> Doing this should be relatively easy. It would be userspace's decision
> whether they want more reliable or faster printk. Sounds fine with me.
I can add it as a separate patch to the series. should be quite trivial.
I have [minor] concerns, though. I can see how, for example, user space
can decide what logging level it wants '1 4 4 7' or anything else, but
how can user space decide what printk implementation it wants to use?
I'm more or less positive not to back-port that `synchronous RW' patch
to the kernels that I use; just because I don't want to give this freedom
to people, sync printk is something I'm trying to run away from.
> > This gets normal scheduling policy, so a spinning userspace SCHED_FIFO
> > task will block printk for ever. This seems bad.
>
> I have to research this a bit but won't the SCHED_FIFO task that has
> potentially unbounded amount of work lockup the CPU even though it does
> occasional cond_resched()?
depending on `watchdog_thresh' value, it can take something like 20+
seconds before watchdog will notice softlockup.
so I'm setting printk kthread prio to `MAX_RT_PRIO - 1' as of now,
just in case.
I think I'll leave printk kthread init as a late_initcall. probably
would prefer core/arch/device init calls to happen in sync printk mode.
-ss
