lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 19 Jan 2021 09:14:28 +0530 From: Viresh Kumar <viresh.kumar@...aro.org> To: Ulf Hansson <ulf.hansson@...aro.org> Cc: Dmitry Osipenko <digetx@...il.com>, Thierry Reding <thierry.reding@...il.com>, Jonathan Hunter <jonathanh@...dia.com>, Peter Geis <pgwipeout@...il.com>, Nicolas Chauvet <kwizart@...il.com>, "Rafael J. Wysocki" <rjw@...ysocki.net>, Kevin Hilman <khilman@...nel.org>, Peter De Schrijver <pdeschrijver@...dia.com>, Viresh Kumar <vireshk@...nel.org>, Stephen Boyd <sboyd@...nel.org>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Matt Merhar <mattmerhar@...tonmail.com>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, linux-tegra <linux-tegra@...r.kernel.org>, Linux PM <linux-pm@...r.kernel.org> Subject: Re: [PATCH v3 1/3] PM: domains: Make set_performance_state() callback optional 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
Powered by blists - more mailing lists