On Wed, 10 Feb 2016 15:36:49 +0100 Petr Mladek <[email protected]> wrote:
> Bcc: > Subject: Re: [PATCH] printk: avoid livelock if another CPU printks > continuously > Reply-To: > In-Reply-To: <[email protected]> > Hmm, playing with mail headers? > > + if (cnt == 0) { > > + /* > > + * Other CPU(s) printk like crazy, filling log_buf[]. > > + * Try to get rid of the "honor" of servicing their data: > > + * give _them_ time to grab console_sem and start working. > > + */ > > + cnt = 9999; > > + while (--cnt != 0) { > > + cpu_relax(); > > + if (console_seq == log_next_seq) { > > This condition is true when all available messages are printed to > the console. It means that there is nothing to do at all. It is > quite late. A much better solution would be to store console_seq > to a local variable and check it is being modified by an other CPU. > Yep, I recommended the same thing. > > > + /* Good, other CPU entered "for(;;)" loop */ > > + goto out; > > + } > > + } > > + /* No one seems to be willing to take it... */ > > + if (console_trylock()) > > + goto again; /* we took it */ > > + /* Nope, someone else holds console_sem! Good */ > > The cycle gives a big chance other CPUs to enter console_unlock(). > It means that more CPUs might end up in the above busy cycle. > > It gives a chance to move the printing to another CPU. It likely > slows down the flood of messages because the producer end up > here as well. > > So, it probably works but the performance is far from optimal. > Many CPUs might end up doing nothing. I am afraid that this is > not the right way to go. Note, it's not that performance critical, and the loop only happens if someone else is adding to the console, which hopefully, should be rare. -- Steve
