On 18-01-21, 13:46, Ulf Hansson wrote: > You seem to be worried about latency/overhead while doing the > propagation upwards in the hierarchy. That seems like a reasonable > concern to me, especially as the genpd lock is taken at each level. I am not sure how many levels of domains we have normally, but unless the number is big it won't be a very big problem. > However, to mitigate this can be rather messy. In principle, we would > need to walk the hierarchy upwards, each time a new subdomain is added > in genpd_add_subdomain(). While doing this, we would also need to keep > track on what level we set to continue the propagation of the > performance states for. Even if this can be done in non-latency > sensitive paths, I don't think it's worth it because of complexity (I > haven't even thought of what happens when removing a subdomain). What about a new field in the domain structure like 'can-handle-pstates', and then whenever sub-domain gets added it just needs to check its parent's field and set his own. > So, maybe we should simply just stick to the existing code, forcing > the parent to have a ->set_performance() callback assigned if > propagation should continue? I think it would be better to fix the issue even if we aren't fully optimized and making the change to make sure we keep propagating is rather important. -- viresh
