On Thu, Jun 11, 2020 at 5:00 AM Sudeep Holla <sudeep.holla@xxxxxxx> wrote: > > > > > Interesting logs ! The time taken to complete _successful_ requests > > > are arguably better in bad_trace ... there are many <10usec responses > > > in bad_trace, while the fastest response in good_trace is 53usec. > > > > Indeed this is interesting. It may be worth looking (separately) into > > why don't we see those 3 us long requests anymore, or maybe they were > > just not there in the logs. > > > > As I mentioned in another thread that non-dvfs requests may be prioritised > lower when there are parallel request to the remote. The so called bad > trace doesn't have such scenario with single channel and all requests > from OS being serialised. The good trace has 2 channels and requests to > remote happen in parallel and hence it is fair to see slightly higher > latencies for lower priority requests. > 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. -#define SCMI_MAX_POLL_TO_NS (100 * NSEC_PER_USEC) +#define SCMI_MAX_POLL_TO_NS (30 * 1000 * NSEC_PER_USEC) The above simple fix (not a hack or workaround) avoids the need of virtual channels' implementation, as per tests you conducted. It might have been silly to not implement virtual channels originally, but it would be just as silly now to implement if we can reuse the code. So I welcome new tests. thanks.
