2017-02-14 17:12 GMT+01:00 Aaron Durbin via coreboot coreboot@coreboot.org:
For an optimized bootflow all pieces of work that need to be done pretty much need to be closely coupled. One needs to globally optimize the full sequence.
Like initializing slow hardware even before RAM init (as long as it's just an initial command)? How about using PIT/IRQ0 plus some tiny register-only interrupt routine to do trivial register wrangling (we do have register scripts)?
that we seem to be absolutely needing to maintain boot speeds. Is Chrome OS going against tide of coreboot wanting to solve those sorts of issues?
The problem is that two basic qualities collide here: speed and simplicity. The effect is that people ask to stop a second to reconsider the options. MPinit and parallelism are the "go to" solution for all performance related issues of the last 10 years, but they're not without cost. Questioning this approach doesn't mean that that we shouldn't go there at all, just that the obvious answers might not lead to simple solutions.
As Andrey stated elsewhere, we're far from CPU bound.
For his concrete example: does eMMC init fail if you ping it more often than every 10ms? It better not, you already stated that it's hard to guarantee those 10ms, so there needs to be some spare room. We could look at the largest chunk of init process that could be restructured to implement cooperative multithreading on a single core for as many tasks as possible, to cut down on all those udelays (or even mdelays). Maybe we could even build a compiler plugin to ensure at compile time that the resulting code is proper (loops either have low bounds or are yielding, yield()/sched()/... aren't called within critical sections)...
Once we leave that scheduling to physics (ie enabling multicore operation), all bets are off (or we have to synchronize the execution to a degree that we could just as well do it manually). A lot of complexity just to have 8 times the CPU power for the same amount of IO bound tasks.
Patrick
-
Patrick Georgi