On Tuesday, 10 July 2007 22:55, Oleg Nesterov wrote: > On 07/10, Rafael J. Wysocki wrote: > > > > On Tuesday, 10 July 2007 19:17, Oleg Nesterov wrote: > > > > > Just watch the "todo", it it doesn't decrease during BREAK_TIMEOUT, then retry. > > > No? > > > > No, it is computed from the start in every interation and I compare the result > > from the previous iteration with the current result. Still, I don't compare 'todo' > > with 'todo from the previous step' directly, because the lock up can only > > happen if 'todo' is equal to 'blocking'. For this reason, it is sufficient to > > compare 'blocking' with 'prev_blocking' (ie. 'blocking' from the previous > > step) and 'todo' with 'blocking' (the test if 'todo' > 0 is not essential; > > well, I should remove it in accordance with my signature ;-)). > > Yes, I see what the code does. My question was: why it is not good enough to just > compare 'todo' with 'todo from the previous step' ? If 'todo' does not decrease > during the BREAK_TIMEOUT period, probably we should retry. A fork() from user-space > should not succeed because we send a fake signal to all tasks. Hmm, yes, I think that's reasonable. I'll try to do it this way Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
