Messages in this thread | | | Date | Wed, 7 May 2014 10:46:23 +0100 | From | Will Deacon <> | Subject | Re: + printk-print-initial-logbuf-contents-before-re-enabling-interrupts.patch added to -mm tree |
| |
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. > > > I'd see that compromise if enabling & disabling interrupts would be > > > taking considerable amount of time. I don't think that was your concern, > > > was it? Maybe I just misunderstood you... > > > > Well, that isn't the quickest operation on ARM (since it's > > self-synchronising), but I was actually referring to the ability to drain > > the log buffer (with interrupts disabled) vs the ability to service > > interrupts quickly. The moment we re-enable interrupts, we can start adding > > more messages to the buffer from the IRQ path (I didn't attempt to solve the > > multi-CPU case, as I mentioned before). > I see. But practically the multi-CPU case is much more common than the > IRQ case, isn't it?
I think they're both pretty niche, but still valid scenarios.
> > > Sure. I have a patch which transitions printing to another CPU once in a > > > while so single CPU isn't hogged for too long and that solves the issues I > > > have observed. But Alan didn't like this solution so the issue is unfixed > > > for now. > > > > Interesting. Do you have a pointer to the thread? > The patchset posting starts here: > https://lkml.org/lkml/2014/3/25/343 > > Patch 5/8 is probably the most interesting for you (patches 1-4 are > already in the mm tree).
Yikes, that's certainly more invasive than anything I had in mind!
Will
| |