On Mon, 2018-05-07 at 19:37 +0200, Frederic Barrat wrote: > > Le 18/04/2018 à 03:08, Alastair D'Silva a écrit : > > From: Alastair D'Silva <alastair@xxxxxxxxxxx> > > > > The current implementation of TID allocation, using a global IDR, > > may > > result in an errant process starving the system of available TIDs. > > Instead, use task_pid_nr(), as mentioned by the original author. > > The > > scenario described which prevented it's use is not applicable, as > > set_thread_tidr can only be called after the task struct has been > > populated. > > > Here is how I understand what's going to happen if 2 threads are > using > the same TIDR value, which is possible with this patch (if unlikely): > > 1. waking up the wrong thread is not really a problem, as threads > have > to handle spurious wake up from the 'wait' instruction anyway, and > must > be using some other condition to know when to loop around the 'wait' > instruction. > > 2. missing the right thread: if the wrong thread is on a CPU, and a > wake_host_thread/as_notify is sent, the core will see a matching > thread > and will accept the command. The (open)capi adapter won't send an > interrupt. The wrong thread is awaken, which is not a problem as > discussed above. As the right thread to notify is not running, no > harm > is done either: as soon as the thread runs, it's supposed to check > its > condition (which will be met) or call 'wait', but 'wait' immediately > returns when called the first time after a thread is scheduled. > > So I believe we are ok. But I think it requires a huge comment with > the > above (at the minimum) :-) > > With a comment: > Reviewed-by: Frederic Barrat <fbarrat@xxxxxxxxxxxxxxxxxx> > > Fred > Good point, I'll add this in the next revision. -- Alastair D'Silva Open Source Developer Linux Technology Centre, IBM Australiamob: 0423 762 819 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
