В Fri, 19 Jul 2019 11:06:05 +0900
Chanwoo Choi <cw00.choi@xxxxxxxxxxx> пишет:
> On 19. 7. 19. 오전 10:59, Dmitry Osipenko wrote:
> > В Fri, 19 Jul 2019 10:36:30 +0900
> > Chanwoo Choi <cw00.choi@xxxxxxxxxxx> пишет:
> >
> >> On 19. 7. 8. 오전 7:32, Dmitry Osipenko wrote:
> >>> I noticed that CPU may be crossing the dependency threshold very
> >>> frequently for some workloads and this results in a lot of
> >>> interrupts which could be avoided if MCALL client is keeping
> >>> actual EMC frequency at a higher rate.
> >>>
> >>> Signed-off-by: Dmitry Osipenko <digetx@xxxxxxxxx>
> >>> ---
> >>> drivers/devfreq/tegra30-devfreq.c | 23 ++++++++++++++++++-----
> >>> 1 file changed, 18 insertions(+), 5 deletions(-)
> >>>
> >>> diff --git a/drivers/devfreq/tegra30-devfreq.c
> >>> b/drivers/devfreq/tegra30-devfreq.c index
> >>> c3cf87231d25..4d582809acb6 100644 ---
> >>> a/drivers/devfreq/tegra30-devfreq.c +++
> >>> b/drivers/devfreq/tegra30-devfreq.c @@ -314,7 +314,8 @@ static
> >>> void tegra_actmon_get_lower_upper(struct tegra_devfreq *tegra, }
> >>>
> >>> static void tegra_devfreq_update_avg_wmark(struct tegra_devfreq
> >>> *tegra,
> >>> - struct
> >>> tegra_devfreq_device *dev)
> >>> + struct
> >>> tegra_devfreq_device *dev,
> >>> + unsigned long freq)
> >>> {
> >>> unsigned long avg_threshold, lower, upper;
> >>>
> >>> @@ -323,6 +324,15 @@ static void
> >>> tegra_devfreq_update_avg_wmark(struct tegra_devfreq *tegra,
> >>> avg_threshold = dev->config->avg_dependency_threshold;
> >>> avg_threshold = avg_threshold * ACTMON_SAMPLING_PERIOD;
> >>> + /*
> >>> + * If cumulative EMC frequency selection is higher than
> >>> the
> >>> + * device's, then there is no need to set upper watermark
> >>> to
> >>> + * a lower value because it will result in unnecessary
> >>> upper
> >>> + * interrupts.
> >>> + */
> >>> + if (freq * ACTMON_SAMPLING_PERIOD > upper)
> >>> + upper = freq * ACTMON_SAMPLING_PERIOD;
> >>
> >> Also, 'upper value is used on the patch5. You can combine this code
> >> to patch5 or if this patch depends on the cpu notifier, you can
> >> combine it to the patch of adding cpu notifier without separate
> >> patch.
> >
> > Well okay, I'll try to squash some of the patches in the next
> > revision. Usually I'm receiving comments in the other direction,
> > asking to separate patches into smaller changes ;) So that's more a
> > personal preference of each maintainer, I'd say.
> >
>
> Right. We have to make the patch with atomic attribute.
> But, if there are patches which touch the same code
> in the same patchset. We can squash or do refactorig
> of this code.
The main benefit of having smaller logical changes is that when there is
a bug, it's easier to narrow down the offending change using bisection.
And it's just easier to review smaller patches, of course.
> And also, if possible, I'd like you to make the patch
> list according to the role of patch. For example,
> the patches related to the 'watermark' could be sequentially
> listed. But, it is not forced opinion. If just possible.
Okay, will take this into account.
