Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1373212
| From | Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH v10 1/2] printk: Make printk() completely async |
| Date | 2016-04-07 11:50 +0200 |
| Message-ID | <rleJA-1Ne-13@gated-at.bofh.it> (permalink) |
| References | <rkfeF-5Fz-9@gated-at.bofh.it> <rkfeG-5Fz-19@gated-at.bofh.it> <rklDr-1IB-5@gated-at.bofh.it> <rkRWH-1G1-29@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH v10 1/2] printk: Make printk() completely async Sergey Senozhatsky <sergey.senozhatsky@gmail.com> - 2016-04-04 18:10 +0200
Re: [PATCH v10 1/2] printk: Make printk() completely async Andrew Morton <akpm@linux-foundation.org> - 2016-04-05 01:00 +0200
Re: [PATCH v10 1/2] printk: Make printk() completely async Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-04-05 07:20 +0200
Re: [PATCH v10 1/2] printk: Make printk() completely async Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-04-05 09:40 +0200
Re: [PATCH v10 1/2] printk: Make printk() completely async Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-04-06 02:20 +0200
Re: [PATCH v10 1/2] printk: Make printk() completely async Jan Kara <jack@suse.cz> - 2016-04-06 11:30 +0200
Re: [PATCH v10 1/2] printk: Make printk() completely async Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-04-07 11:50 +0200
Re: [PATCH v10 1/2] printk: Make printk() completely async Sergey Senozhatsky <sergey.senozhatsky@gmail.com> - 2016-04-07 13:20 +0200
Re: [PATCH v10 1/2] printk: Make printk() completely async Jan Kara <jack@suse.cz> - 2016-04-07 15:20 +0200
csiph-web