> I thought that this would automatically reduce processor load, which is > obviously not the case. Sorry for the delay, but i am trying to figure > out how to slow down write method when under pressure. Ok I played with this a bit. Much to my surprise until I thought about it in detail it all works fine without any of the ratelimiting at all. There is a problem if you manage to redirect the console *in kernel* to the printk driver, but that needs stopping anyway and rate limit won't fix it (you blow the stack before it kicks in) In the case where userspace loads it hard and its a graphical console then we use a lot of CPU power drawing stuff on screen, but killing the process does as is expected. With a serial console the printk itself blocks which blocks the line discipline which in turn slows stuff down. The only two bad things I can see how to cause are - Slowing down output by stuffing lots of extra data into the port (which I can do anyway just fine) so isn't worse than before. - Filling up the dmesg log easily and hiding important messages. Not really a problem in this case bcause the whole point of this is embedded and capturing those messages as if they were system ones. So much to my surprise the flow control is a red herring and best left out. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
