From: Saravana Kannan <skannan@codeaurora.org> To: "Srivatsa S. Bhat" <srivatsa@MIT.EDU> Cc: Viresh Kumar <viresh.kumar@linaro.org>, "Rafael J . Wysocki" <rjw@rjwysocki.net>, Todd Poynor <toddpoynor@google.com>, "linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, "linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, Stephen Boyd <sboyd@codeaurora.org> Subject: Re: [PATCH v3 1/2] cpufreq: Don't destroy/realloc policy/sysfs on hotplug/suspend Date: Wed, 16 Jul 2014 12:56:28 -0700 [thread overview] Message-ID: <53C6D8EC.1030609@codeaurora.org> (raw) In-Reply-To: <53C65F03.1050609@mit.edu> On 07/16/2014 04:16 AM, Srivatsa S. Bhat wrote: > On 07/16/2014 01:54 PM, Viresh Kumar wrote: >> On 16 July 2014 04:17, Saravana Kannan <skannan@codeaurora.org> wrote: >>> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c >> <SNIP> >>> -static int cpufreq_add_policy_cpu(struct cpufreq_policy *policy, >>> - unsigned int cpu, struct device *dev) >>> +static int cpufreq_change_policy_cpus(struct cpufreq_policy *policy, >>> + unsigned int cpu, bool add) > > [...] > >>> - >>> - if (!cpufreq_driver->setpolicy) >>> - strncpy(per_cpu(cpufreq_cpu_governor, cpu), >>> - policy->governor->name, CPUFREQ_NAME_LEN); >> >> Where is this gone? There are several instances of code just being >> removed, this is the third one. Its really really tough to catch these >> in this big of a patch. Believe me. >> >> You have to break this patch into multiple ones, see this on how to >> break even simplest of the changes into multiple patches: >> https://lkml.org/lkml/2013/9/6/400 >> >> Its just impossible to catch bugs that you might have introduced here due >> to the size of this patch. And its taking a LOT of time for me to review this. >> As I have to keep diff in one tab, new cpufreq.c in one and the old cpufreq.c >> in one and then compare.. >> > > True, this is still a pretty huge chunk. Saravana, at this stage, don't worry > about making cpufreq work properly in each and every patch. Just ensure that > every patch builds fine; that should be good enough. I hope this will help you > in splitting up the patches further. Thanks Srivatsa. This will definitely help split them up into smaller chunks. > One other thing: your changelog contains what we usually write in a cover- > letter - *very* high-level goals of the patch. Ideally, you should explain > the subtle details and the non-obvious decisions or trade-offs that you have > made at various places in the code. Otherwise it becomes very hard to follow > your thought-flow just by looking at the patch. So please split up the patch > further and also make the changelogs useful to review the patch :-) Thanks. Will do. > The link that Viresh gave above also did a lot of code reorganization in > cpufreq, so it should give you a good example of how to proceed. > > [...] > >>> __cpufreq_add_dev(dev, NULL); >>> break; >>> >>> case CPU_DOWN_PREPARE: >>> - __cpufreq_remove_dev_prepare(dev, NULL); >>> - break; >>> - >>> - case CPU_POST_DEAD: >>> - __cpufreq_remove_dev_finish(dev, NULL); >>> - break; >>> - >>> - case CPU_DOWN_FAILED: >>> - __cpufreq_add_dev(dev, NULL); >>> + __cpufreq_remove_dev(dev, NULL); >> >> @Srivatsa: You might want to have a look at this, remove sequence was >> separated for some purpose and I am just not able to concentrate enough >> to think of that, just too many cases running in my mind :) >> > > Yeah, we had split it into _remove_dev_prepare() and _remove_dev_finish() > to avoid a few potential deadlocks. We wanted to call _remove_dev_prepare() > in the DOWN_PREPARE stage and then call _remove_dev_finish() (which waits > for the kobject refcount to drop) in the POST_DEAD stage. That is, we wanted > to do the kobject cleanup after releasing the hotplug lock, and POST_DEAD stage > was well-suited for that. > > Commit 1aee40ac9c8 (cpufreq: Invoke __cpufreq_remove_dev_finish() after > releasing cpu_hotplug.lock) explains this in detail. Saravana, please take a > look at that reasoning and ensure that your patch doesn't re-introduce those > deadlock possibilities! But all of that was needed _because_ we were creating and destroying policies and kobjs all the time. We don't do that anymore. So, I don't think any of that applies. We only destroy when the cpufreq driver is unregistered. That's kinda of the point of this patchset. Thoughts? -Saravana -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation
WARNING: multiple messages have this Message-ID (diff)
From: skannan@codeaurora.org (Saravana Kannan) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH v3 1/2] cpufreq: Don't destroy/realloc policy/sysfs on hotplug/suspend Date: Wed, 16 Jul 2014 12:56:28 -0700 [thread overview] Message-ID: <53C6D8EC.1030609@codeaurora.org> (raw) In-Reply-To: <53C65F03.1050609@mit.edu> On 07/16/2014 04:16 AM, Srivatsa S. Bhat wrote: > On 07/16/2014 01:54 PM, Viresh Kumar wrote: >> On 16 July 2014 04:17, Saravana Kannan <skannan@codeaurora.org> wrote: >>> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c >> <SNIP> >>> -static int cpufreq_add_policy_cpu(struct cpufreq_policy *policy, >>> - unsigned int cpu, struct device *dev) >>> +static int cpufreq_change_policy_cpus(struct cpufreq_policy *policy, >>> + unsigned int cpu, bool add) > > [...] > >>> - >>> - if (!cpufreq_driver->setpolicy) >>> - strncpy(per_cpu(cpufreq_cpu_governor, cpu), >>> - policy->governor->name, CPUFREQ_NAME_LEN); >> >> Where is this gone? There are several instances of code just being >> removed, this is the third one. Its really really tough to catch these >> in this big of a patch. Believe me. >> >> You have to break this patch into multiple ones, see this on how to >> break even simplest of the changes into multiple patches: >> https://lkml.org/lkml/2013/9/6/400 >> >> Its just impossible to catch bugs that you might have introduced here due >> to the size of this patch. And its taking a LOT of time for me to review this. >> As I have to keep diff in one tab, new cpufreq.c in one and the old cpufreq.c >> in one and then compare.. >> > > True, this is still a pretty huge chunk. Saravana, at this stage, don't worry > about making cpufreq work properly in each and every patch. Just ensure that > every patch builds fine; that should be good enough. I hope this will help you > in splitting up the patches further. Thanks Srivatsa. This will definitely help split them up into smaller chunks. > One other thing: your changelog contains what we usually write in a cover- > letter - *very* high-level goals of the patch. Ideally, you should explain > the subtle details and the non-obvious decisions or trade-offs that you have > made at various places in the code. Otherwise it becomes very hard to follow > your thought-flow just by looking at the patch. So please split up the patch > further and also make the changelogs useful to review the patch :-) Thanks. Will do. > The link that Viresh gave above also did a lot of code reorganization in > cpufreq, so it should give you a good example of how to proceed. > > [...] > >>> __cpufreq_add_dev(dev, NULL); >>> break; >>> >>> case CPU_DOWN_PREPARE: >>> - __cpufreq_remove_dev_prepare(dev, NULL); >>> - break; >>> - >>> - case CPU_POST_DEAD: >>> - __cpufreq_remove_dev_finish(dev, NULL); >>> - break; >>> - >>> - case CPU_DOWN_FAILED: >>> - __cpufreq_add_dev(dev, NULL); >>> + __cpufreq_remove_dev(dev, NULL); >> >> @Srivatsa: You might want to have a look at this, remove sequence was >> separated for some purpose and I am just not able to concentrate enough >> to think of that, just too many cases running in my mind :) >> > > Yeah, we had split it into _remove_dev_prepare() and _remove_dev_finish() > to avoid a few potential deadlocks. We wanted to call _remove_dev_prepare() > in the DOWN_PREPARE stage and then call _remove_dev_finish() (which waits > for the kobject refcount to drop) in the POST_DEAD stage. That is, we wanted > to do the kobject cleanup after releasing the hotplug lock, and POST_DEAD stage > was well-suited for that. > > Commit 1aee40ac9c8 (cpufreq: Invoke __cpufreq_remove_dev_finish() after > releasing cpu_hotplug.lock) explains this in detail. Saravana, please take a > look at that reasoning and ensure that your patch doesn't re-introduce those > deadlock possibilities! But all of that was needed _because_ we were creating and destroying policies and kobjs all the time. We don't do that anymore. So, I don't think any of that applies. We only destroy when the cpufreq driver is unregistered. That's kinda of the point of this patchset. Thoughts? -Saravana -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation
next prev parent reply other threads:[~2014-07-16 19:56 UTC|newest] Thread overview: 205+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-07-10 2:37 [PATCH] cpufreq: Don't destroy/realloc policy/sysfs on hotplug/suspend Saravana Kannan 2014-07-10 2:37 ` Saravana Kannan 2014-07-11 4:18 ` [PATCH v2] " Saravana Kannan 2014-07-11 4:18 ` Saravana Kannan 2014-07-11 6:19 ` Viresh Kumar 2014-07-11 6:19 ` Viresh Kumar 2014-07-11 6:19 ` Viresh Kumar 2014-07-11 9:59 ` skannan 2014-07-11 9:59 ` skannan at codeaurora.org 2014-07-11 9:59 ` skannan 2014-07-11 10:07 ` skannan 2014-07-11 10:07 ` skannan at codeaurora.org 2014-07-11 10:07 ` skannan 2014-07-11 10:52 ` Viresh Kumar 2014-07-11 10:52 ` Viresh Kumar 2014-07-11 10:52 ` Viresh Kumar 2014-07-12 2:44 ` Saravana Kannan 2014-07-12 2:44 ` Saravana Kannan 2014-07-12 2:44 ` Saravana Kannan 2014-07-14 6:09 ` Viresh Kumar 2014-07-14 6:09 ` Viresh Kumar 2014-07-14 6:09 ` Viresh Kumar 2014-07-14 19:08 ` Saravana Kannan 2014-07-14 19:08 ` Saravana Kannan 2014-07-14 19:08 ` Saravana Kannan 2014-07-15 4:35 ` Viresh Kumar 2014-07-15 4:35 ` Viresh Kumar 2014-07-15 4:35 ` Viresh Kumar 2014-07-15 5:36 ` Saravana Kannan 2014-07-15 5:36 ` Saravana Kannan 2014-07-15 5:36 ` Saravana Kannan 2014-07-15 5:52 ` Viresh Kumar 2014-07-15 5:52 ` Viresh Kumar 2014-07-15 5:52 ` Viresh Kumar 2014-07-15 6:58 ` Srivatsa S. Bhat 2014-07-15 6:58 ` Srivatsa S. Bhat 2014-07-15 6:58 ` Srivatsa S. Bhat 2014-07-15 17:35 ` skannan 2014-07-15 17:35 ` skannan at codeaurora.org 2014-07-15 17:35 ` skannan 2014-07-16 7:44 ` Srivatsa S. Bhat 2014-07-16 7:44 ` Srivatsa S. Bhat 2014-07-16 7:44 ` Srivatsa S. Bhat 2014-07-16 5:44 ` Viresh Kumar 2014-07-16 5:44 ` Viresh Kumar 2014-07-16 5:44 ` Viresh Kumar 2014-07-16 7:49 ` Srivatsa S. Bhat 2014-07-16 7:49 ` Srivatsa S. Bhat 2014-07-16 7:49 ` Srivatsa S. Bhat 2014-07-12 3:06 ` Saravana Kannan 2014-07-12 3:06 ` Saravana Kannan 2014-07-12 3:06 ` Saravana Kannan 2014-07-14 6:13 ` Viresh Kumar 2014-07-14 6:13 ` Viresh Kumar 2014-07-14 6:13 ` Viresh Kumar 2014-07-14 19:10 ` Saravana Kannan 2014-07-14 19:10 ` Saravana Kannan 2014-07-14 19:10 ` Saravana Kannan 2014-07-11 7:43 ` Srivatsa S. Bhat 2014-07-11 7:43 ` Srivatsa S. Bhat 2014-07-11 10:02 ` skannan 2014-07-11 10:02 ` skannan at codeaurora.org 2014-07-15 22:47 ` [PATCH v3 0/2] Simplify hotplug/suspend handling Saravana Kannan 2014-07-15 22:47 ` Saravana Kannan 2014-07-15 22:47 ` [PATCH v3 1/2] cpufreq: Don't destroy/realloc policy/sysfs on hotplug/suspend Saravana Kannan 2014-07-15 22:47 ` Saravana Kannan 2014-07-16 0:28 ` Saravana Kannan 2014-07-16 0:28 ` Saravana Kannan 2014-07-16 8:30 ` Viresh Kumar 2014-07-16 8:30 ` Viresh Kumar 2014-07-16 8:30 ` Viresh Kumar 2014-07-16 19:19 ` Saravana Kannan 2014-07-16 19:19 ` Saravana Kannan 2014-07-16 19:19 ` Saravana Kannan 2014-07-16 8:24 ` Viresh Kumar 2014-07-16 8:24 ` Viresh Kumar 2014-07-16 8:24 ` Viresh Kumar 2014-07-16 11:16 ` Srivatsa S. Bhat 2014-07-16 11:16 ` Srivatsa S. Bhat 2014-07-16 11:16 ` Srivatsa S. Bhat 2014-07-16 13:13 ` Viresh Kumar 2014-07-16 13:13 ` Viresh Kumar 2014-07-16 13:13 ` Viresh Kumar 2014-07-16 18:04 ` Srivatsa S. Bhat 2014-07-16 18:04 ` Srivatsa S. Bhat 2014-07-16 18:04 ` Srivatsa S. Bhat 2014-07-16 19:56 ` Saravana Kannan 2014-07-16 19:56 ` Saravana Kannan 2014-07-16 19:56 ` Saravana Kannan 2014-07-17 5:51 ` Viresh Kumar 2014-07-17 5:51 ` Viresh Kumar 2014-07-17 5:51 ` Viresh Kumar 2014-07-16 19:56 ` Saravana Kannan [this message] 2014-07-16 19:56 ` Saravana Kannan 2014-07-16 19:56 ` Saravana Kannan 2014-07-17 5:35 ` Viresh Kumar 2014-07-17 5:35 ` Viresh Kumar 2014-07-17 5:35 ` Viresh Kumar 2014-07-18 3:25 ` Saravana Kannan 2014-07-18 3:25 ` Saravana Kannan 2014-07-18 3:25 ` Saravana Kannan 2014-07-18 4:19 ` Viresh Kumar 2014-07-18 4:19 ` Viresh Kumar 2014-07-18 4:19 ` Viresh Kumar 2014-07-16 20:25 ` Saravana Kannan 2014-07-16 20:25 ` Saravana Kannan 2014-07-16 20:25 ` Saravana Kannan 2014-07-16 21:45 ` Saravana Kannan 2014-07-16 21:45 ` Saravana Kannan 2014-07-16 21:45 ` Saravana Kannan 2014-07-17 6:24 ` Viresh Kumar 2014-07-17 6:24 ` Viresh Kumar 2014-07-17 6:24 ` Viresh Kumar 2014-07-16 14:29 ` Dirk Brandewie 2014-07-16 14:29 ` Dirk Brandewie 2014-07-16 15:28 ` Viresh Kumar 2014-07-16 15:28 ` Viresh Kumar 2014-07-16 15:28 ` Viresh Kumar 2014-07-16 19:42 ` Saravana Kannan 2014-07-16 19:42 ` Saravana Kannan 2014-07-16 19:42 ` Saravana Kannan 2014-07-15 22:47 ` [PATCH v3 2/2] cpufreq: Simplify and fix mutual exclusion with hotplug Saravana Kannan 2014-07-15 22:47 ` Saravana Kannan 2014-07-16 8:48 ` Viresh Kumar 2014-07-16 8:48 ` Viresh Kumar 2014-07-16 8:48 ` Viresh Kumar 2014-07-16 19:34 ` Saravana Kannan 2014-07-16 19:34 ` Saravana Kannan 2014-07-16 19:34 ` Saravana Kannan 2014-07-25 1:07 ` [PATCH v4 0/5] Simplify hotplug/suspend handling Saravana Kannan 2014-07-25 1:07 ` Saravana Kannan 2014-07-25 1:07 ` [PATCH v4 1/5] cpufreq: Don't wait for CPU to going offline to restart governor Saravana Kannan 2014-07-25 1:07 ` Saravana Kannan 2014-07-31 20:47 ` Saravana Kannan 2014-07-31 20:47 ` Saravana Kannan 2014-07-25 1:07 ` [PATCH v4 2/5] cpufreq: Keep track of which CPU owns the kobj/sysfs nodes separately Saravana Kannan 2014-07-25 1:07 ` Saravana Kannan 2014-08-07 9:02 ` Viresh Kumar 2014-08-07 9:02 ` Viresh Kumar 2014-08-07 9:02 ` Viresh Kumar 2014-07-25 1:07 ` [PATCH v4 3/5] cpufreq: Don't destroy/realloc policy/sysfs on hotplug/suspend Saravana Kannan 2014-07-25 1:07 ` Saravana Kannan 2014-07-31 21:56 ` Rafael J. Wysocki 2014-07-31 21:56 ` Rafael J. Wysocki 2014-07-31 22:15 ` Saravana Kannan 2014-07-31 22:15 ` Saravana Kannan 2014-07-31 23:48 ` Saravana Kannan 2014-07-31 23:48 ` Saravana Kannan 2014-07-31 23:48 ` Saravana Kannan 2014-08-07 10:51 ` Viresh Kumar 2014-08-07 10:51 ` Viresh Kumar 2014-08-07 10:51 ` Viresh Kumar 2014-08-12 9:17 ` Viresh Kumar 2014-08-12 9:17 ` Viresh Kumar 2014-08-12 9:17 ` Viresh Kumar 2014-08-07 10:48 ` Viresh Kumar 2014-08-07 10:48 ` Viresh Kumar 2014-08-07 10:48 ` Viresh Kumar 2014-08-11 22:13 ` Saravana Kannan 2014-08-11 22:13 ` Saravana Kannan 2014-08-11 22:13 ` Saravana Kannan 2014-08-12 8:51 ` Viresh Kumar 2014-08-12 8:51 ` Viresh Kumar 2014-08-12 8:51 ` Viresh Kumar 2014-07-25 1:07 ` [PATCH v4 4/5] cpufreq: Properly handle physical CPU hot-add/hot-remove Saravana Kannan 2014-07-25 1:07 ` Saravana Kannan 2014-07-25 1:07 ` Saravana Kannan 2014-08-07 11:02 ` Viresh Kumar 2014-08-07 11:02 ` Viresh Kumar 2014-08-07 11:02 ` Viresh Kumar 2014-08-11 22:15 ` Saravana Kannan 2014-08-11 22:15 ` Saravana Kannan 2014-08-11 22:15 ` Saravana Kannan 2014-07-25 1:07 ` [PATCH v4 5/5] cpufreq: Delete dead code related to policy save/restore Saravana Kannan 2014-07-25 1:07 ` Saravana Kannan 2014-08-07 11:06 ` Viresh Kumar 2014-08-07 11:06 ` Viresh Kumar 2014-08-07 11:06 ` Viresh Kumar 2014-07-29 5:52 ` [PATCH v4 0/5] Simplify hotplug/suspend handling skannan 2014-07-29 5:52 ` skannan at codeaurora.org 2014-07-29 5:52 ` skannan 2014-07-30 0:29 ` Rafael J. Wysocki 2014-07-30 0:29 ` Rafael J. Wysocki 2014-07-31 20:25 ` Saravana Kannan 2014-07-31 20:25 ` Saravana Kannan 2014-08-07 6:04 ` skannan 2014-08-07 6:04 ` skannan at codeaurora.org 2014-10-16 8:53 ` Viresh Kumar 2014-10-16 8:53 ` Viresh Kumar 2014-10-16 8:53 ` Viresh Kumar 2014-10-23 21:41 ` Saravana Kannan 2014-10-23 21:41 ` Saravana Kannan 2014-10-23 21:41 ` Saravana Kannan 2014-07-16 22:02 ` [PATCH] cpufreq: Don't destroy/realloc policy/sysfs on hotplug/suspend Rafael J. Wysocki 2014-07-16 22:02 ` Rafael J. Wysocki 2014-07-16 22:35 ` Saravana Kannan 2014-07-16 22:35 ` Saravana Kannan 2014-07-24 3:02 ` Saravana Kannan 2014-07-24 3:02 ` Saravana Kannan 2014-07-24 5:04 ` Viresh Kumar 2014-07-24 5:04 ` Viresh Kumar 2014-07-24 5:04 ` Viresh Kumar 2014-07-24 9:12 ` skannan 2014-07-24 9:12 ` skannan at codeaurora.org 2014-07-24 9:12 ` skannan
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=53C6D8EC.1030609@codeaurora.org \ --to=skannan@codeaurora.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-arm-msm@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-pm@vger.kernel.org \ --cc=rjw@rjwysocki.net \ --cc=sboyd@codeaurora.org \ --cc=srivatsa@MIT.EDU \ --cc=toddpoynor@google.com \ --cc=viresh.kumar@linaro.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.