Hi,
On 02/13/2017 12:31 PM, ron minnich wrote:
Another idea just popped up: Performing "background" tasks in udelay() / mdelay() implementations ;)that is adurbin's threading model. I really like it.
A lot of times, concurrency will get you just as far as ||ism without the nastiness.
But how do you guarantee code will get a slice of execution time when it needs it? For example for eMMC link training you need to issue certain commands with certain time interval. Lets say every 10ms. How do you make sure that happens? You can keep track of time and see when next piece of work needs to be scheduled, but how do you guarantee you enter this udelay code often enough?
Andrey
andrey, great questions. If you're really concerned about those issues, then yes, maybe a space sharing solution is the right one.
I really would rather not see people implementing schedulers at this point. If we're going to go that route, let's get a reasonable operating system and use it instead. If we continue on coreboot's current trajectory we're going to end up like every other firmware project that became an OS, and that to me is the wrong direction.
ron
On Mon, Feb 13, 2017 at 6:43 PM Andrey Petrov andrey.petrov@intel.com wrote:
Hi,
On 02/13/2017 12:31 PM, ron minnich wrote:
Another idea just popped up: Performing "background" tasks inudelay()
/ mdelay() implementations ;)that is adurbin's threading model. I really like it.
A lot of times, concurrency will get you just as far as ||ism without the nastiness.
But how do you guarantee code will get a slice of execution time when it needs it? For example for eMMC link training you need to issue certain commands with certain time interval. Lets say every 10ms. How do you make sure that happens? You can keep track of time and see when next piece of work needs to be scheduled, but how do you guarantee you enter this udelay code often enough?
Andrey
On Mon, Feb 13, 2017 at 8:43 PM, Andrey Petrov andrey.petrov@intel.com wrote:
Hi,
On 02/13/2017 12:31 PM, ron minnich wrote:
Another idea just popped up: Performing "background" tasks in udelay() / mdelay() implementations ;)that is adurbin's threading model. I really like it.
A lot of times, concurrency will get you just as far as ||ism without the nastiness.
But how do you guarantee code will get a slice of execution time when it needs it? For example for eMMC link training you need to issue certain commands with certain time interval. Lets say every 10ms. How do you make sure that happens? You can keep track of time and see when next piece of work needs to be scheduled, but how do you guarantee you enter this udelay code often enough?
You can't guarantee anything like that. You'd need compiler help for yielding at loop and function boundaries. Or you go the interrupt route and reschedule. Or you use the other CPUs like you already mentioned.
coreboot code base is not currently sympathetic to multiple threads with full pre-emption. The threads currently provided in coreboot do yielding in udelay calls as a safe place to reschedule. That by no means provides any latency guarantees and since we have no concept of work we can't ensure there's a guaranteed latency between each chunk of work.
Andrey
-- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
-
Aaron Durbin -
Andrey Petrov -
ron minnich