Re: (Big) problems achieving fair scheduling of a semaphore ISR producer - thread consumer case


Paul Sokolovsky
 

On Fri, 7 Apr 2017 09:06:14 +0100
Daniel Thompson <daniel.thompson@linaro.org> wrote:

[]

So, it's a typical "nothing works" type of bug each of us faced and
enjoyed. I really need 2nd (3rd, 4th) opinion on this. My kind
request though is: please don't try to shift it all on UART and
talk about the need of DTR/RTS, etc. UART is damn slow device by
the current standards, which should "just work" with dozens-of-MHz
CPUs without any flow control on hardware side.
If the UART TX side produces more characters than it receives in
input then flow control (or very large buffers) are the *only* way to
avoid losing characters when the input is running at maximum speed.

Anything with a character echo and a longer message on each '\n' will
eventually overflow unless we use flow control (or bound the input).

One possible mitigation would be to provide with an API to determin
if the pull-console is backlogging. If that happens than an
application might choose to disable its character echo to help it
catch up.

I remember yesterday you said you had disabled all the local echos...
did you reach a point where the TX/RX ratio was less than 1:1?
Ok, master, following patch:

--- a/samples/subsys/console/getchar/src/main.c
+++ b/samples/subsys/console/getchar/src/main.c
@@ -9,6 +9,6 @@ void main(void)
while (1) {
uint8_t c = console_getchar();

- printk("char: [0x%x] %c\n", c, c);
+// printk("char: [0x%x] %c\n", c, c);
}
}

...
Console buffer overflow - char dropped
Console buffer overflow - char dropped
...

So, kindly let me keep repeating it again - the problem is not with
UART, the problem is with scheduling a thread which is woken up on a
sema signaled in ISR. (Yes, it would be nice to reproduce that with
another IRQ but UART).

The only way I was able to achieve 1:1 ration is by applying incorrect
k_yield patch to qemu_x86 build - that works flawless and perfectly
(printing "+" on k_sem_give, "-" on k_sem_take produces the expected
pattern of "+-+-+-+-+-" whereas in other cases the pattern is like
"+++++++++++++++++++++++++++++++++++-+++++++++++-++++++++++++++-").



Daniel.


--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

Join devel@lists.zephyrproject.org to automatically receive all group messages.