After having a relaxing day, once I said:
"I like your idea that if we did not want to do something on the stuck CPU
then treat the CPU as stopped."
but now I noticed that the stuck CPU can harm what we want to do if it is
not real stuck... ex. busy loop in a subsystem, and we want to touch the
core of the subsystem exclusively.
So "force progress" is not safe, on some rare case. I'd like to make this
timeout feature as a safe-net, therefore we should return error without
taking a risk even it would be small, I think.
I suppose my current implementation, returning control to user immediately,
is better than looping in main thread. In my implementation, num_threads is
initialized to num_online_cpus() by main thread, and decremented 1 by 1
each child thread. If time out happen, main thread will return without
waiting completion but set state STOPMACHINE_EXIT. Then child threads are now
detached from usual procedure, so they exit soon without do any work.
At the beginning of new stop_machine, we can check the num_threads to know
whether there are remaining child threads. If there are, something is wrong
since the system cannot run MAX_PRIO RT thread, not binded to typical cpu now.
So we can return error in such case, assuming that the new stop_machine will
fail in same way.
Anyway, I also think we can better thing here, but we don't need to do all
at once. Making steps by incremental patches would be nice, I think.
Thanks,
H.Seto
--
