On Thu 13-03-14 16:06:25, Andrew Morton wrote:
> On Thu, 13 Mar 2014 16:58:37 +0100 Jan Kara wrote:
>
> > Currently, console_unlock() prints messages from kernel printk buffer to
> > console while the buffer is non-empty. When serial console is attached,
> > printing is slow and thus other CPUs i
On Thu 13-03-14 16:06:25, Andrew Morton wrote:
> On Thu, 13 Mar 2014 16:58:37 +0100 Jan Kara wrote:
>
> > Currently, console_unlock() prints messages from kernel printk buffer to
> > console while the buffer is non-empty. When serial console is attached,
> > printing is slow and thus other CPUs i
On Thu 13-03-14 23:26:36, One Thousand Gnomes wrote:
> > Creating yet more kernel threads to solve this problem is a bit sad.
> > Is there no way in which we can borrow one of the existing threads?
>
> schedule_work()
>
> Surely that's all we need, if we get bunged up for a bit then it ends up
>
> Creating yet more kernel threads to solve this problem is a bit sad.
> Is there no way in which we can borrow one of the existing threads?
schedule_work()
Surely that's all we need, if we get bunged up for a bit then it ends up
on a work queue item and everyone with a billion disks and a 9600
On Thu, 13 Mar 2014 16:58:37 +0100 Jan Kara wrote:
> Currently, console_unlock() prints messages from kernel printk buffer to
> console while the buffer is non-empty. When serial console is attached,
> printing is slow and thus other CPUs in the system have plenty of time
> to append new messages
Currently, console_unlock() prints messages from kernel printk buffer to
console while the buffer is non-empty. When serial console is attached,
printing is slow and thus other CPUs in the system have plenty of time
to append new messages to the buffer while one CPU is printing. Thus the
CPU can sp
6 matches
Mail list logo
