On Thu 08-05-14 15:34:07, Will Deacon wrote:
> Hi Alan,
>
> On Wed, May 07, 2014 at 05:41:51PM +0100, One Thousand Gnomes wrote:
> > > Possibly, but I fear we'd incur the wrath of Alan after reading that other
> > > thread. Having a CONFIG_ option or similar to control the amount of
> > >
On Thu 08-05-14 15:34:07, Will Deacon wrote:
Hi Alan,
On Wed, May 07, 2014 at 05:41:51PM +0100, One Thousand Gnomes wrote:
Possibly, but I fear we'd incur the wrath of Alan after reading that other
thread. Having a CONFIG_ option or similar to control the amount of
printing
we do
Hi Alan,
On Wed, May 07, 2014 at 05:41:51PM +0100, One Thousand Gnomes wrote:
> > Possibly, but I fear we'd incur the wrath of Alan after reading that other
> > thread. Having a CONFIG_ option or similar to control the amount of printing
> > we do is very similar to the command-line option Jan
Hi Alan,
On Wed, May 07, 2014 at 05:41:51PM +0100, One Thousand Gnomes wrote:
Possibly, but I fear we'd incur the wrath of Alan after reading that other
thread. Having a CONFIG_ option or similar to control the amount of printing
we do is very similar to the command-line option Jan proposed
> Possibly, but I fear we'd incur the wrath of Alan after reading that other
> thread. Having a CONFIG_ option or similar to control the amount of printing
> we do is very similar to the command-line option Jan proposed in his series.
I've nothing against a configuration option, and having a
On Tue, May 06, 2014 at 11:05:53PM +0100, Andrew Morton wrote:
> On Tue, 6 May 2014 14:12:34 +0100 Will Deacon wrote:
> > > > > My opinion is that when you are printing from each and every interrupt
> > > > > which happens so often, then you have a problem and disabling IRQs in
> > > > > printk
On Tue, May 06, 2014 at 09:00:22PM +0100, Jan Kara wrote:
> On Tue 06-05-14 16:00:37, Will Deacon wrote:
> > On Tue, May 06, 2014 at 03:00:32PM +0100, Jan Kara wrote:
> > > On Tue 06-05-14 14:12:34, Will Deacon wrote:
> > > > Right, so there's the usual compromise here between throughput and
> >
On Tue, May 06, 2014 at 09:00:22PM +0100, Jan Kara wrote:
On Tue 06-05-14 16:00:37, Will Deacon wrote:
On Tue, May 06, 2014 at 03:00:32PM +0100, Jan Kara wrote:
On Tue 06-05-14 14:12:34, Will Deacon wrote:
Right, so there's the usual compromise here between throughput and
latency.
On Tue, May 06, 2014 at 11:05:53PM +0100, Andrew Morton wrote:
On Tue, 6 May 2014 14:12:34 +0100 Will Deacon will.dea...@arm.com wrote:
My opinion is that when you are printing from each and every interrupt
which happens so often, then you have a problem and disabling IRQs in
Possibly, but I fear we'd incur the wrath of Alan after reading that other
thread. Having a CONFIG_ option or similar to control the amount of printing
we do is very similar to the command-line option Jan proposed in his series.
I've nothing against a configuration option, and having a printk
On Tue, 6 May 2014 14:12:34 +0100 Will Deacon wrote:
> > > > My opinion is that when you are printing from each and every interrupt
> > > > which happens so often, then you have a problem and disabling IRQs in
> > > > printk so that your interrupt doesn't happen that often seems like a
> > > >
On Tue 06-05-14 16:00:37, Will Deacon wrote:
> On Tue, May 06, 2014 at 03:00:32PM +0100, Jan Kara wrote:
> > On Tue 06-05-14 14:12:34, Will Deacon wrote:
> > > On Tue, May 06, 2014 at 01:29:58PM +0100, Jan Kara wrote:
> > > > Well, with serial console the backlog can get actually pretty big.
>
On Tue, May 06, 2014 at 03:00:32PM +0100, Jan Kara wrote:
> On Tue 06-05-14 14:12:34, Will Deacon wrote:
> > On Tue, May 06, 2014 at 01:29:58PM +0100, Jan Kara wrote:
> > > Well, with serial console the backlog can get actually pretty big.
> > > During
> > > boot on large machines I've seen
On Tue 06-05-14 14:12:34, Will Deacon wrote:
> On Tue, May 06, 2014 at 01:29:58PM +0100, Jan Kara wrote:
> > On Tue 06-05-14 13:06:48, Will Deacon wrote:
> > > On Fri, May 02, 2014 at 11:46:51PM +0100, Jan Kara wrote:
> > > > I really dislike this patch. It goes completely against my efforts of
On Tue, May 06, 2014 at 02:12:34PM +0100, Will Deacon wrote:
> That said, printing one message each time seems to go too far in the
> opposite direction for my liking, so the best bet is likely to limit the
> work to some fixed number of messages. Do you have any feeling for such a
> limit?
42!
On Tue, May 06, 2014 at 01:29:58PM +0100, Jan Kara wrote:
> On Tue 06-05-14 13:06:48, Will Deacon wrote:
> > On Fri, May 02, 2014 at 11:46:51PM +0100, Jan Kara wrote:
> > > I really dislike this patch. It goes completely against my efforts of
> > > lowering irq latency caused by printing to
On Tue 06-05-14 13:06:48, Will Deacon wrote:
> Hello,
>
> On Fri, May 02, 2014 at 11:46:51PM +0100, Jan Kara wrote:
> > On Fri 02-05-14 14:22:20, Andrew Morton wrote:
> > > From: Will Deacon
> > > Subject: printk: print initial logbuf contents before re-enabling
> > > interrupts
> > >
> > >
Hello,
On Fri, May 02, 2014 at 11:46:51PM +0100, Jan Kara wrote:
> On Fri 02-05-14 14:22:20, Andrew Morton wrote:
> > From: Will Deacon
> > Subject: printk: print initial logbuf contents before re-enabling interrupts
> >
> > When running on a hideously slow system (~10Mhz FPGA) with a bunch of
Hello,
On Fri, May 02, 2014 at 11:46:51PM +0100, Jan Kara wrote:
On Fri 02-05-14 14:22:20, Andrew Morton wrote:
From: Will Deacon will.dea...@arm.com
Subject: printk: print initial logbuf contents before re-enabling interrupts
When running on a hideously slow system (~10Mhz FPGA) with a
On Tue 06-05-14 13:06:48, Will Deacon wrote:
Hello,
On Fri, May 02, 2014 at 11:46:51PM +0100, Jan Kara wrote:
On Fri 02-05-14 14:22:20, Andrew Morton wrote:
From: Will Deacon will.dea...@arm.com
Subject: printk: print initial logbuf contents before re-enabling
interrupts
On Tue, May 06, 2014 at 01:29:58PM +0100, Jan Kara wrote:
On Tue 06-05-14 13:06:48, Will Deacon wrote:
On Fri, May 02, 2014 at 11:46:51PM +0100, Jan Kara wrote:
I really dislike this patch. It goes completely against my efforts of
lowering irq latency caused by printing to console
On Tue, May 06, 2014 at 02:12:34PM +0100, Will Deacon wrote:
That said, printing one message each time seems to go too far in the
opposite direction for my liking, so the best bet is likely to limit the
work to some fixed number of messages. Do you have any feeling for such a
limit?
42!
On Tue 06-05-14 14:12:34, Will Deacon wrote:
On Tue, May 06, 2014 at 01:29:58PM +0100, Jan Kara wrote:
On Tue 06-05-14 13:06:48, Will Deacon wrote:
On Fri, May 02, 2014 at 11:46:51PM +0100, Jan Kara wrote:
I really dislike this patch. It goes completely against my efforts of
On Tue, May 06, 2014 at 03:00:32PM +0100, Jan Kara wrote:
On Tue 06-05-14 14:12:34, Will Deacon wrote:
On Tue, May 06, 2014 at 01:29:58PM +0100, Jan Kara wrote:
Well, with serial console the backlog can get actually pretty big.
During
boot on large machines I've seen CPUs stuck in
On Tue 06-05-14 16:00:37, Will Deacon wrote:
On Tue, May 06, 2014 at 03:00:32PM +0100, Jan Kara wrote:
On Tue 06-05-14 14:12:34, Will Deacon wrote:
On Tue, May 06, 2014 at 01:29:58PM +0100, Jan Kara wrote:
Well, with serial console the backlog can get actually pretty big.
During
On Tue, 6 May 2014 14:12:34 +0100 Will Deacon will.dea...@arm.com wrote:
My opinion is that when you are printing from each and every interrupt
which happens so often, then you have a problem and disabling IRQs in
printk so that your interrupt doesn't happen that often seems like a
On Fri 02-05-14 14:22:20, Andrew Morton wrote:
> From: Will Deacon
> Subject: printk: print initial logbuf contents before re-enabling interrupts
>
> When running on a hideously slow system (~10Mhz FPGA) with a bunch of
> debug printk invocations on the timer interrupt path, we end up filling
>
On Fri 02-05-14 14:22:20, Andrew Morton wrote:
From: Will Deacon will.dea...@arm.com
Subject: printk: print initial logbuf contents before re-enabling interrupts
When running on a hideously slow system (~10Mhz FPGA) with a bunch of
debug printk invocations on the timer interrupt path, we end
28 matches
Mail list logo
