Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1385717 > unrolled thread
| Started by | Pavel Machek <pavel@ucw.cz> |
|---|---|
| First post | 2016-04-23 21:50 +0200 |
| Last post | 2016-04-24 16:10 +0200 |
| Articles | 4 — 2 participants |
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.
Re: [RFC][PATCH v6 0/2] printk: Make printk() completely async Pavel Machek <pavel@ucw.cz> - 2016-04-23 21:50 +0200
Re: [RFC][PATCH v6 0/2] printk: Make printk() completely async Sergey Senozhatsky <sergey.senozhatsky@gmail.com> - 2016-04-24 06:20 +0200
Re: [RFC][PATCH v6 0/2] printk: Make printk() completely async Pavel Machek <pavel@ucw.cz> - 2016-04-24 15:40 +0200
Re: [RFC][PATCH v6 0/2] printk: Make printk() completely async Sergey Senozhatsky <sergey.senozhatsky@gmail.com> - 2016-04-24 16:10 +0200
| From | Pavel Machek <pavel@ucw.cz> |
|---|---|
| Date | 2016-04-23 21:50 +0200 |
| Subject | Re: [RFC][PATCH v6 0/2] printk: Make printk() completely async |
| Message-ID | <rrbIZ-a3-3@gated-at.bofh.it> |
On Tue 2016-03-22 07:49:48, Jan Kara wrote:
> Hi,
>
> On Tue 22-03-16 02:25:28, Sergey Senozhatsky wrote:
> > The patch set is based on slightly updated Jan Kara's patches.
> >
> > This patch set makes printk() completely asynchronous: new messages
> > are getting upended to the kernel printk buffer, but instead of 'direct'
> > printing the actual print job is performed by a dedicated kthread.
> > This has the advantage that printing always happens from a schedulable
> > context and thus we don't lockup any particular CPU or even interrupts.
> >
> > The patch set is against next-20160321
> >
> > the series in total has 3 patches:
> > - printk: Make printk() completely async
> > - printk: Make wake_up_klogd_work_func() async
> > - printk: make console_unlock() async
> >
> > per discussion, "printk: make console_unlock() async" will be posted
> > later on.
>
> Patches look good to me. I don't think you need to mention the
> console_unlock() async patch when it is not part of the series. BTW, you
> seemed to have dropped my patch to skip if there are too many buffered
> messages when oops is in progress. Any reason for that?
So... from basically linux 0.0, cli() printk("") could be used for
debugging. ... and that's now gone. Right?
Can you explain why that is good idea?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[toc] | [next] | [standalone]
| From | Sergey Senozhatsky <sergey.senozhatsky@gmail.com> |
|---|---|
| Date | 2016-04-24 06:20 +0200 |
| Message-ID | <rrjGx-6KF-1@gated-at.bofh.it> |
| In reply to | #1385717 |
On (04/23/16 21:40), Pavel Machek wrote:
[..]
> > > The patch set is against next-20160321
> > >
> > > the series in total has 3 patches:
> > > - printk: Make printk() completely async
> > > - printk: Make wake_up_klogd_work_func() async
> > > - printk: make console_unlock() async
> > >
> > > per discussion, "printk: make console_unlock() async" will be posted
> > > later on.
> >
> > Patches look good to me. I don't think you need to mention the
> > console_unlock() async patch when it is not part of the series. BTW, you
> > seemed to have dropped my patch to skip if there are too many buffered
> > messages when oops is in progress. Any reason for that?
>
> So... from basically linux 0.0, cli() printk("") could be used for
> debugging. ... and that's now gone. Right?
>
> Can you explain why that is good idea?
it's not gone. you need to explicitly enable async printk mode. the case
you mentioned -- cli() printk("")->console_unlock() -- apart from being
useful in some scenarios, can cause problems in others, simply because
under some circumstances it can run forever, as long as there are printk()
calls coming from other CPUs (which can happen during, f.e., debugging).
did you mean UP systems? well, async printk is sort of useless on UP systems
anyway.
-ss
[toc] | [prev] | [next] | [standalone]
| From | Pavel Machek <pavel@ucw.cz> |
|---|---|
| Date | 2016-04-24 15:40 +0200 |
| Message-ID | <rrsqu-5lc-7@gated-at.bofh.it> |
| In reply to | #1385771 |
On Sun 2016-04-24 14:14:49, Sergey Senozhatsky wrote:
> On (04/23/16 21:40), Pavel Machek wrote:
> [..]
> > > > The patch set is against next-20160321
> > > >
> > > > the series in total has 3 patches:
> > > > - printk: Make printk() completely async
> > > > - printk: Make wake_up_klogd_work_func() async
> > > > - printk: make console_unlock() async
> > > >
> > > > per discussion, "printk: make console_unlock() async" will be posted
> > > > later on.
> > >
> > > Patches look good to me. I don't think you need to mention the
> > > console_unlock() async patch when it is not part of the series. BTW, you
> > > seemed to have dropped my patch to skip if there are too many buffered
> > > messages when oops is in progress. Any reason for that?
> >
> > So... from basically linux 0.0, cli() printk("") could be used for
> > debugging. ... and that's now gone. Right?
> >
> > Can you explain why that is good idea?
>
> it's not gone. you need to explicitly enable async printk mode. the case
> you mentioned -- cli() printk("")->console_unlock() -- apart from being
> useful in some scenarios, can cause problems in others, simply because
> under some circumstances it can run forever, as long as there are printk()
> calls coming from other CPUs (which can happen during, f.e., debugging).
> did you mean UP systems? well, async printk is sort of useless on UP systems
> anyway.
Well, yes, it has been long known that printk() can take long
time.. Still that's not a problem for smaller system.
Now, patch set above says "Make printk() completely async" -- so I
assumed that it does...
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[toc] | [prev] | [next] | [standalone]
| From | Sergey Senozhatsky <sergey.senozhatsky@gmail.com> |
|---|---|
| Date | 2016-04-24 16:10 +0200 |
| Message-ID | <rrsTv-5Uj-1@gated-at.bofh.it> |
| In reply to | #1385814 |
On (04/24/16 15:35), Pavel Machek wrote:
[..]
> > > So... from basically linux 0.0, cli() printk("") could be used for
> > > debugging. ... and that's now gone. Right?
> > >
> > > Can you explain why that is good idea?
> >
> > it's not gone. you need to explicitly enable async printk mode. the case
> > you mentioned -- cli() printk("")->console_unlock() -- apart from being
> > useful in some scenarios, can cause problems in others, simply because
> > under some circumstances it can run forever, as long as there are printk()
> > calls coming from other CPUs (which can happen during, f.e., debugging).
> > did you mean UP systems? well, async printk is sort of useless on UP systems
> > anyway.
>
> Well, yes, it has been long known that printk() can take long
> time.. Still that's not a problem for smaller system.
well, embedded systems can have slow serial consoles (so
console_unlock()->call_consoles_drivers() endup in uart/etc
device driver). and small systems are the systems where I
see problems with printk.
> Now, patch set above says "Make printk() completely async" -- so I
> assumed that it does...
that's my bad, sorry. I didn't keep an eye on the cover letter
(except for the changelog).
-ss
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web