On Mon 2019-03-11 11:51:49, John Ogness wrote:
> On 2019-03-07, Sergey Senozhatsky wrote:
> > I don't really understand the role of loglevel anymore.
>
> "what the kernel considers" is a configuration option of the
> administrator. The administrator can increase the verbocity of the
> console
On (03/11/19 11:51), John Ogness wrote:
> > In new printk design the tasks are still affected by printing floods.
> > Tasks have to line up and (busy) wait for each other, regardless of
> > contexts.
>
> They only line up and busy wait is to add the informational message to
> the ring buffer. The
On 2019-03-07, Sergey Senozhatsky wrote:
>> The current printk implementation will do a better job of getting the
>> informational messages out, but at an enormous cost to all the tasks
>> on the system (including the realtime tasks). I am proposing a printk
>> implementation where the tasks are
On Fri 2019-03-08 10:31:34, Sergey Senozhatsky wrote:
> On (03/07/19 13:06), John Ogness wrote:
> > On 2019-03-04, Sergey Senozhatsky wrote:
> > > This, theoretically, creates a whole new world of possibilities for
> > > console drivers. Now they can do GFP_KERNEL allocations and stall
> > >
On (03/07/19 13:06), John Ogness wrote:
> On 2019-03-04, Sergey Senozhatsky wrote:
> >> + /* the printk kthread never exits */
> >> + for (;;) {
> >> + ret = prb_iter_wait_next(, buf,
> >> + PRINTK_RECORD_MAX, _seq);
> >> + if (ret ==
On Wed 2019-03-06 22:17:12, John Ogness wrote:
> On 2019-03-06, Petr Mladek wrote:
> >> I would like to clarify that message supression (i.e. console loglevel)
> >> is a method of reducing what is printed. It does nothing to address the
> >> issues related to console printing. My proposal
On 2019-03-04, Sergey Senozhatsky wrote:
>> +/* the printk kthread never exits */
>> +for (;;) {
>> +ret = prb_iter_wait_next(, buf,
>> + PRINTK_RECORD_MAX, _seq);
>> +if (ret == -ERESTARTSYS) {
>> +continue;
On (03/07/19 15:41), Sergey Senozhatsky wrote:
> This sounds concerning. IMHO, netconsole is too important to rely
> on preemptible printk and scheduler. Especially those netcons which
> run in "report only when oops_in_progress" mode. Sometimes netconsole
> is the fastest console available, but
On (03/06/19 23:22), John Ogness wrote:
> On 2019-03-06, Petr Mladek wrote:
> >> _Both_ categories are important for the user, but their requirements
> >> are different:
> >>
> >>informational: non-disturbing
> >>emergency: reliable
> >
> > Isn't this already handled by the
Hi John,
On (03/05/19 22:00), John Ogness wrote:
> Hi Sergey,
>
[..]
> Console printing is a convenient feature to allow a kernel to
> communicate information to a user without any reliance on
> userspace. IMHO there are 2 categories of messages that the kernel will
> communicate. The first is
On 2019-03-06, Petr Mladek wrote:
>> _Both_ categories are important for the user, but their requirements
>> are different:
>>
>>informational: non-disturbing
>>emergency: reliable
>
> Isn't this already handled by the console_level?
>
> The informational messages can be reliably
On 2019-03-06, Petr Mladek wrote:
>> I would like to clarify that message supression (i.e. console loglevel)
>> is a method of reducing what is printed. It does nothing to address the
>> issues related to console printing. My proposal focusses on addressing
>> the issues related to console
On Tue 2019-03-05 22:00:58, John Ogness wrote:
> Hi Sergey,
>
> Thanks for your feedback.
>
> I am responding to this comment ahead of your previous comments because
> it really cuts at the heart of the proposed design. After addressing
> this point it will make it easier for me to respond to
Hi Sergey,
Thanks for your feedback.
I am responding to this comment ahead of your previous comments because
it really cuts at the heart of the proposed design. After addressing
this point it will make it easier for me to respond to your other
comments.
NOTE: This is a lengthy response.
On
On (03/04/19 19:00), Sergey Senozhatsky wrote:
>
> But in general, channels which depend on preemptible printk will become
> totally useless in some cases.
>
Which brings me to a question - what are those messages/channels?
Not important enough to be printed on consoles immediately, yet
On (03/04/19 16:38), Sergey Senozhatsky wrote:
> This, theoretically, creates a whole new world of possibilities for
> console drivers. Now they can do GFP_KERNEL allocations and stall
> printk_kthread during OOM; or they can explicitly reschedule from
> ->write() callback (via
On (02/12/19 15:29), John Ogness wrote:
[..]
> + /* the printk kthread never exits */
> + for (;;) {
> + ret = prb_iter_wait_next(, buf,
> + PRINTK_RECORD_MAX, _seq);
> + if (ret == -ERESTARTSYS) {
> +
On Tue 2019-02-12 15:29:46, John Ogness wrote:
> The printk ring buffer provides an NMI-safe interface for writing
> messages to a ring buffer. Using such a buffer for alleviates printk
> callers from the current burdens of disabled preemption while calling
> the console drivers (and possibly
On (02/12/19 15:29), John Ogness wrote:
[..]
> +static int printk_kthread_func(void *data)
> +{
> + struct prb_iterator iter;
> + struct printk_log *msg;
> + size_t ext_len;
> + char *ext_text;
> + u64 master_seq;
> + size_t len;
> + char *text;
> + char *buf;
> +
The printk ring buffer provides an NMI-safe interface for writing
messages to a ring buffer. Using such a buffer for alleviates printk
callers from the current burdens of disabled preemption while calling
the console drivers (and possibly printing out many messages that
another task put into the
20 matches
Mail list logo
