[lkml]   [2000]   [Jul]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: a joint letter on low latency and Linux
Martin Mares said this...
>> Note that printk() during normal kernel operations _is_ a bug.
>> printk() should happen only for (a) initialization and (b) exceptional
>> events. I fyou get printk's while doing streaming audio, you have other
>> trouble, and whatever causes that trouble should be fixed.
> Agreed. But if we want to allow printk's in those emergency situations, we
>still must lock the console subsystem somehow to avoid collisions between
>normal console output and the printk's. The most ugly point is that some
>gfx cards (Matrox, to name one) lock up when trying to touch the frame buffer
>while the accelerator accesses it. And these locks definitely should not
>keep interrupts disabled as they do now. Being a sssslllooowww action,
>scrolling of the FB should be interruptible and perhaps even preemptive.

I'm not sure why printk() needs to have a complicated algorithm. Under
normal circumstances (that were pointed out above) (a) happens on boot and
there shouldn't be much problem with locks, and (b) only happens when
there's a problem so even if it is slow in this case, it's only reporting
that something went wrong (or some debugging messages that would be
removed before the code is 'published'.)

I admit that I'm very much a newbie here, but it seems that the effort to
make a faster printk() would be better off in other areas, since, in the
best of all worlds, it wouldn't ever be used during normal operation


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:57    [W:0.045 / U:39.520 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site