Messages in this thread | | | Date | Sun, 2 Jul 2000 12:45:02 -0700 (PDT) | From | Chris Lattner <> | Subject | Re: [PATCH #2] console lock grabbed too early in printk... |
| |
> It sounds like you really need a private macro or private debugging > code, not a modification to a function which nearly all kernel code > calls at one time or another.
Take a look at my "patch #3" to see if it looks "better". It's not calling any dangerous functions and it gives other advantages (lowever console_lock contention... it might be better?
> I don't think too many people are going to favor changing printk to be > optimal for "quick debugging checks"... which involve userland > addresses and/or paging. printk should be optimal, sure, but this is > NOT a case the core kernel needs to optimize for.
But my point all along is that it only addes a spin_lock and spin_unlock on a very low contended lock (unless you're doing tons of printk's, in which you would spin on the console_lock isntead) to the common case. Only the uncommon case that you only hit durring debugging gets effected...
> > I'll throw together a > > new patch that will hopefully address some problems... > What exactly are those problems?
Well, from the general kernel perspective there's a highly contended console_lock that is having to be held through a vsprintf, and in my perspective, deadlock is not happy. :)
-Chris
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |