On 11-06-20, 19:34, Jassi Brar wrote: > In the first post in this thread, Viresh lamented that mailbox > introduces "a few ms" delay in the scheduler path. > Your own tests show that is certainly not the case -- average is the > same as proposed virtual channels 50-100us, the best case is 3us vs > 53us for virtual channels. Hmmm, I am not sure where is the confusion here Jassi. There are two things which are very very different from each other. - Time taken by the mailbox framework (and remote for acknowledging it) for completion of a single request, this can be 3us to 100s of us. This is clear for everyone. THIS IS NOT THE PROBLEM. - Delay introduced by few of such requests on the last one, i.e. 5 normal requests followed by an important one (like DVFS), the last one needs to wait for the first 5 to finish first. THIS IS THE PROBLEM. Just increasing the timeout isn't going to solve anything as I said in the last email, we can make it 5 minutes for what's its worth. The idea is to make the turn-around-time less for all the requests.. >From Google (I know you must already know it, I am just trying to highlight the importance of this thing here): Turnaround time (TAT) is the time interval from the time of submission of a process (read request) to the time of the completion of the process. This is what people care about, that is the whole reason kernel has multi-processing support in the first place. If making things sequential was good enough, we would have never reached here. The whole idea is to parallelize things as much as possible without hurting efficiency in a bad way (like too much parallelism). The hardware allows parallelism and there is absolutely no point in not allowing that. The kernel doesn't need to worry about how the remote is going to handle it. Remote may be simple and handle it sequentially or it may be running Linux itself and can schedule multiple threads for requests. -- viresh
