Messages in this thread | | | Date | Thu, 7 Nov 2013 18:37:17 -0500 | From | Steven Rostedt <> | Subject | Re: [PATCH 3/4] printk: Defer printing to irq work when we printed too much |
| |
On Fri, 8 Nov 2013 00:21:51 +0100 Frederic Weisbecker <fweisbec@gmail.com> wrote:
> Ok I see now. > > But then this irq_work based solution won't work if, say, you run in full dynticks > mode. Also the hook on the timer interrupt is something that I wish we get rid > of on archs that can trigger self-IPIs.
Do we really want that? What about users that use LAZY? That is, the work isn't that important to trigger right now (added interrupt expense).
> > Notwithstanding it's going to have scalibility issues as irq work then converges > to a single list for unbound works.
Well, it doesn't seem to be something that would be called often. All CPUs checking a variable that is seldom changed should not have any scalability issues. Unless of course it happens to share a cache line with a variable that does change often.
> > Offloading to a workqueue would be perhaps better, and writing to the serial > console could then be done with interrupts enabled, preemptible context, etc...
Oh God no ;-) Adding workqueue logic into printk just spells a nightmare of much more complexity for a critical kernel infrastructure.
-- Steve
| |