Dne 27.06.2010 (ned) ob 14:35 +0100 je Alan Cox zapisal(a): > > 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 If without flow control, do you think it makes sense to very slowly introduce more and more delay (interruptible) into tty's write operation when output rate is "too" high? That way non-error conditions would not suffer (not discarding any messages, only delaying additional 1 msec on 100 writes), when ratelimit would have been exceeded from time to time. And on the other hand endless high-volume output, which is probably an error condition, would slowly give away more and more of its processing time. Maybe this would also help if output is made on behalf of some high RT-prioritized process? Of course, i can easily remove ratelimiting as well, if the situation with flow control isn't clear and this only complicates things. Samo -- 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
