On 15/06/16 17:56, Alex Bennée wrote: > Sergey Fedorov <serge.f...@gmail.com> writes: (snip) > Just some quick comments for context: > >> Alex's reiteration of Fred's approach [2]: >> - maintains a single global safe work queue; > Having separate queues can lead to problems with draining queues as only > queue gets drained at a time and some threads exit more frequently than > others.
I think it can't happen if we drain all the queues from all the CPUs, as we should. The requirement is: stop all the CPUs and process all the pending work. If we follow this requirement, I think it's not important whether we have separate queues for each CPU or just a single global queue. > >> - uses GArray rather than linked list to implement the work queue; > This was to minimise g_malloc on job creation and working through the > list. An awful lot of jobs just need the CPU id and a single parameter. > This is why I made it the simple case. I think it would be nice to avoid g_malloc but don't use an array at the same time. I have some thoughts how to do this easily, let's see the code ;-) >> - introduces a global counter of CPUs which have entered their execution >> loop; >> - makes use of the last CPU exited its execution loop to drain the safe >> work queue; > I suspect you can still race with other deferred work as those tasks are > being done outside the exec loop. This should be fixable though. Will keep an eye on this, thanks. > >> - still does not support user-mode emulation. > There is not particular reason it couldn't. However it would mean > updating the linux-user cpu_exec loop which most likely needs a good > clean-up and re-factoring to avoid making the change to $ARCH loops. Yes, you are right, I just fixed the facts here :) Kind regards, Sergey
