Hello,
On (07/02/17 22:27), Pavel Machek wrote:
[..]
> > +#define PRINTK_FLOOD_DEFAULT_DELAY 10
> > +
> > int printk_delay_msec __read_mostly;
>
> = 10;
the idea is to throttle printk() only (and as long as) when we see
that something is not right. like when we added 4 (a random number)
times m
On Mon 2017-07-03 20:11:30, Sergey Senozhatsky wrote:
> On (06/30/17 22:38), Sergey Senozhatsky wrote:
> > On (06/30/17 15:16), Petr Mladek wrote:
> > > Anyway, the handshake during offloading might be pretty
> > > problematic. To be honest, I do not have much experience
> > > with it. I have share
Hello,
Petr, thanks for commenting/taking a look
On (07/04/17 16:03), Petr Mladek wrote:
> On Fri 2017-06-30 21:42:24, Sergey Senozhatsky wrote:
> > Hello,
> >
> > On (06/30/17 13:54), Petr Mladek wrote:
> > > > but.
> > > > the opposite possibility is that messages either won't be printed
>
On Fri 2017-06-30 21:42:24, Sergey Senozhatsky wrote:
> Hello,
>
> On (06/30/17 13:54), Petr Mladek wrote:
> > > but.
> > > the opposite possibility is that messages either won't be printed
> > > soon (until next printk or console_unlock()) or won't be printed
> > > ever at all (in case of sud
On (07/04/17 14:26), Sergey Senozhatsky wrote:
[..]
> not sure if we can properly throttle printk in all of the cases.
> we know that console_sem is locked, but we don't know what for.
> is CPU that owns the console_sem is now in console_unlock() or
> somewhere in fbcon, or anywhere else. we probab
On (07/03/17 15:34), Steven Rostedt wrote:
> > +#define PRINTK_FLOOD_DEFAULT_DELAY 10
> > +
> > int printk_delay_msec __read_mostly;
> >
> > +static inline void __printk_delay(int m)
> > +{
> > + while (m--) {
> > + mdelay(1);
> > + touch_nmi_watchdog();
> > + }
> > +}
>
On Mon, 3 Jul 2017 20:11:30 +0900
Sergey Senozhatsky wrote:
> +#define PRINTK_FLOOD_DEFAULT_DELAY 10
> +
> int printk_delay_msec __read_mostly;
>
> +static inline void __printk_delay(int m)
> +{
> + while (m--) {
> + mdelay(1);
> + touch_nmi_watchdog();
> + }
On (06/30/17 22:38), Sergey Senozhatsky wrote:
> On (06/30/17 15:16), Petr Mladek wrote:
> > Anyway, the handshake during offloading might be pretty
> > problematic. To be honest, I do not have much experience
> > with it. I have shared some my fears in the other mail[1].
> > Jan Kara spent a lot o
On (06/30/17 10:45), Steven Rostedt wrote:
> On Fri, 30 Jun 2017 23:28:51 +0900
> Sergey Senozhatsky wrote:
>
> > I guess the question was, a knob that would determine what happens after
> > current wakes up printk_kthread -- does it stay in console_unlock() and
> > wait for new console_sem owner
On Fri, 30 Jun 2017 23:28:51 +0900
Sergey Senozhatsky wrote:
> I guess the question was, a knob that would determine what happens after
> current wakes up printk_kthread -- does it stay in console_unlock() and
> wait for new console_sem owner, printing the messages in the meantime,
> or goes all
On (06/30/17 09:33), Steven Rostedt wrote:
[..]
> > "something sometime in the future" is equal to "no one".
> >
> > we must stay and continue printing. because it gives the right
> > answer - "current process and right now. until someone else
> > (+printk_kthread) takes over".
>
> Would it be ac
On (06/30/17 15:16), Petr Mladek wrote:
[..]
>
> I wonder if I could add some counter into task_struct.
> It might be configurable. I am not sure if people would
> want this enabled on production systems where the level
> of messages should be lower anyway.
I don't think it really matters which on
On (06/30/17 15:16), Petr Mladek wrote:
> Anyway, the handshake during offloading might be pretty
> problematic. To be honest, I do not have much experience
> with it. I have shared some my fears in the other mail[1].
> Jan Kara spent a lot of time on this and probably could
> say more.
>
> Maybe,
On Fri, 30 Jun 2017 21:42:24 +0900
Sergey Senozhatsky wrote:
> I apply a very simple litmus test. if the answer to the question
> "so we leave console_unlock() and there are pending messages,
> who and when is going to flush the remaining messages?" is
> "something sometime in the future" then it
On Fri 2017-06-30 16:01:31, Sergey Senozhatsky wrote:
> we are doing our best in order to avoid lockups caused by console_unlock(),
> but the top priority remains messages print out. If we can't guarantee that
> anything will take over and print the messages, we continue printing from
> the current
adead.org,
> r...@rjwysocki.net, ebied...@xmission.com, gre...@linuxfoundation.org,
> jsl...@suse.com, pa...@ucw.cz, a...@lisas.de, linux-kernel@vger.kernel.org
> Subject: Re: [RFC][PATCHv3 2/5] printk: introduce printing kernel thread
> X-Mailer: Winbiff [Version 2.51 PL2]
>
> Sergey Se
Hello,
On (06/30/17 13:54), Petr Mladek wrote:
> > but.
> > the opposite possibility is that messages either won't be printed
> > soon (until next printk or console_unlock()) or won't be printed
> > ever at all (in case of sudden system death). I don't think it's
> > a good alternative.
>
> I
Sergey Senozhatsky wrote:
> On (06/30/17 19:18), Tetsuo Handa wrote:
> > > I'm still thinking about Steven's proposals; but we will need offloading
> > > anyways, so the bits we are talking about here are important regardless
> > > the direction printk design will take, I think.
> >
> > Is there a
On (06/30/17 19:18), Tetsuo Handa wrote:
> Sergey Senozhatsky wrote:
> > if (!alloc_cpumask_var(&cpus_allowed, GFP_KERNEL)) {
> > wake_up_process(printk_kthread);
> > return true;
> > }
>
> Please avoid memory allocations when trying to print somethi
On Thu 2017-06-29 16:33:22, Sergey Senozhatsky wrote:
> On (06/28/17 14:19), Petr Mladek wrote:
> [..]
> > > at the same we have better guarantees.
> > > we don't just wakeup(printk_kthread) and leave. we wait for any other
> > > process to re-take the console_sem. until this happens we can't leave
Sergey Senozhatsky wrote:
> if (!alloc_cpumask_var(&cpus_allowed, GFP_KERNEL)) {
> wake_up_process(printk_kthread);
> return true;
> }
Please avoid memory allocations when trying to print something.
__GFP_DIRECT_RECLAIM allocations (e.g. GFP_KERNEL)
Hello,
On (06/29/17 16:33), Sergey Senozhatsky wrote:
[..]
> On (06/28/17 14:19), Petr Mladek wrote:
> [..]
> > > so I try to minimize the negative impact of RT prio here. printk_kthread
> > > is not special any more. it's an auxiliary kthread that we sometimes
> > > wake_up. the thing is that pri
Sergey Senozhatsky wrote:
> On (06/28/17 14:19), Petr Mladek wrote:
> > Our two proposals are very close after all. I suggest to make
> > the following changes in your patch:
> >
> > + Remove the waiting for another console_lock owner. It is
> > too tricky.
>
> we lose the printing guarante
On (06/28/17 15:17), Petr Mladek wrote:
> On Thu 2017-06-01 16:21:02, Sergey Senozhatsky wrote:
> > On (05/31/17 16:30), Sergey Senozhatsky wrote:
> > > On (05/29/17 14:12), Jan Kara wrote:
> > > [..]
> > > > Actually I had something very similar in old versions of my patch set.
> > > > And
> > >
On (06/28/17 14:19), Petr Mladek wrote:
[..]
> > so I try to minimize the negative impact of RT prio here. printk_kthread
> > is not special any more. it's an auxiliary kthread that we sometimes
> > wake_up. the thing is that printk_kthread also must offload at some
> > point, basically the same `a
On Thu, Jun 29, 2017 at 08:26:20AM +0200, Andreas Mohr wrote:
> On Wed, Jun 28, 2017 at 02:19:25PM +0200, Petr Mladek wrote:
> > On Wed 2017-05-31 16:22:33, Sergey Senozhatsky wrote:
> > > so I try to minimize the negative impact of RT prio here. printk_kthread
> > > is not special any more. it's a
On Wed, Jun 28, 2017 at 02:19:25PM +0200, Petr Mladek wrote:
> On Wed 2017-05-31 16:22:33, Sergey Senozhatsky wrote:
> > so I try to minimize the negative impact of RT prio here. printk_kthread
> > is not special any more. it's an auxiliary kthread that we sometimes
> > wake_up. the thing is that p
On Thu 2017-06-01 16:21:02, Sergey Senozhatsky wrote:
> On (05/31/17 16:30), Sergey Senozhatsky wrote:
> > On (05/29/17 14:12), Jan Kara wrote:
> > [..]
> > > Actually I had something very similar in old versions of my patch set. And
> > > it didn't work very well. The problem was that e.g. sometim
On Wed 2017-05-31 16:30:59, Sergey Senozhatsky wrote:
> Hello Jan,
>
> On (05/29/17 14:12), Jan Kara wrote:
> [..]
> > Actually I had something very similar in old versions of my patch set. And
> > it didn't work very well. The problem was that e.g. sometimes scheduler
> > decided that printk kthr
On Wed 2017-05-31 16:22:33, Sergey Senozhatsky wrote:
> Hello Petr,
>
> On (05/29/17 11:29), Petr Mladek wrote:
> [..]
> > > +static inline bool console_offload_printing(void)
> > > +{
> > > + * A trivial emergency enforcement - give up on printk_kthread if
> > > + * we can't wake it up. This as
On (06/01/17 16:21), Sergey Senozhatsky wrote:
> On (05/31/17 16:30), Sergey Senozhatsky wrote:
> > On (05/29/17 14:12), Jan Kara wrote:
> > [..]
> > > Actually I had something very similar in old versions of my patch set. And
> > > it didn't work very well. The problem was that e.g. sometimes sche
On (06/01/17 16:21), Sergey Senozhatsky wrote:
> On (05/31/17 16:30), Sergey Senozhatsky wrote:
> > On (05/29/17 14:12), Jan Kara wrote:
> > [..]
> > > Actually I had something very similar in old versions of my patch set. And
> > > it didn't work very well. The problem was that e.g. sometimes sche
On (05/31/17 16:30), Sergey Senozhatsky wrote:
> On (05/29/17 14:12), Jan Kara wrote:
> [..]
> > Actually I had something very similar in old versions of my patch set. And
> > it didn't work very well. The problem was that e.g. sometimes scheduler
> > decided that printk kthread should run on the s
On Wed, May 31, 2017 at 04:30:59PM +0900, Sergey Senozhatsky wrote:
> Hello Jan,
>
> On (05/29/17 14:12), Jan Kara wrote:
> [..]
> > Actually I had something very similar in old versions of my patch set. And
> > it didn't work very well. The problem was that e.g. sometimes scheduler
> > decided th
Hello Jan,
On (05/29/17 14:12), Jan Kara wrote:
[..]
> Actually I had something very similar in old versions of my patch set. And
> it didn't work very well. The problem was that e.g. sometimes scheduler
> decided that printk kthread should run on the same CPU as the process
> currently doing prin
Hello Petr,
On (05/29/17 11:29), Petr Mladek wrote:
[..]
> > +static inline bool console_offload_printing(void)
> > +{
> > + static struct task_struct *printing_task;
> > + static unsigned long long lines_printed;
> > + static unsigned long saved_csw;
> > +
> > + if (!printk_offloading_ena
On Mon 29-05-17 11:29:06, Petr Mladek wrote:
> On Wed 2017-05-10 14:59:35, Sergey Senozhatsky wrote:
> > This patch introduces a '/sys/module/printk/parameters/atomic_print_limit'
> > sysfs param, which sets the limit on number of lines a process can print
> > from console_unlock(). Value 0 corresp
On Wed 2017-05-10 14:59:35, Sergey Senozhatsky wrote:
> This patch introduces a '/sys/module/printk/parameters/atomic_print_limit'
> sysfs param, which sets the limit on number of lines a process can print
> from console_unlock(). Value 0 corresponds to the current behavior (no
> limitation). The p
fix !PRINTK config build.
(Reported-by: kbuild test robot ).
From: Sergey Senozhatsky
Subject: [PATCH 2/5] printk: introduce printing kernel thread
printk() is quite complex internally and, basically, it does two
slightly independent things:
a) adds a new message to a kern
39 matches
Mail list logo
