2007-02-18 21:44:08

by Oleg Nesterov

Subject: [PATCH 2/3] cpufreq_ondemand.c: don't use _WORK_NAR

Looks like dbs_timer() is very careful wrt per_cpu(cpu_dbs_info),
and it doesn't need the help of WORK_STRUCT_NOAUTOREL.

Signed-off-by: Oleg Nesterov <[email protected]>

--- WQ/drivers/cpufreq/cpufreq_ondemand.c~2_cpufreq 2007-02-18 22:56:47.000000000 +0300
+++ WQ/drivers/cpufreq/cpufreq_ondemand.c 2007-02-19 00:07:46.000000000 +0300
@@ -432,9 +432,6 @@ static void do_dbs_timer(struct work_str
/* We want all CPUs to do sampling nearly on same jiffy */
int delay = usecs_to_jiffies(dbs_tuners_ins.sampling_rate);

- /* Permit rescheduling of this work item */
- work_release(work);
-
delay -= jiffies % delay;

if (lock_policy_rwsem_write(cpu) < 0)
@@ -473,7 +470,7 @@ static inline void dbs_timer_init(struct
dbs_info->enable = 1;
ondemand_powersave_bias_init();
dbs_info->sample_type = DBS_NORMAL_SAMPLE;
- INIT_DELAYED_WORK_NAR(&dbs_info->work, do_dbs_timer);
+ INIT_DELAYED_WORK(&dbs_info->work, do_dbs_timer);
queue_delayed_work_on(dbs_info->cpu, kondemand_wq, &dbs_info->work,
delay);
}

2007-02-19 11:34:32

by David Howells

Subject: Re: [PATCH 2/3] cpufreq_ondemand.c: don't use _WORK_NAR

Oleg Nesterov <[email protected]> wrote:

> Looks like dbs_timer() is very careful wrt per_cpu(cpu_dbs_info),
> and it doesn't need the help of WORK_STRUCT_NOAUTOREL.

Actually, I think my problem with this was dbs_info->sample_type, but reading
it again, I'm not sure that it's actually a problem as the work function will
probably not ever be executing on two or more CPUs simultaneously because of
the deferral time involved.

So, your patch is probably fair enough. Certainly, deletion isn't a problem.

Acked-By: David Howells <[email protected]>