All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 2/3] cpufreq_ondemand.c: don't use _WORK_NAR
@ 2007-02-18 21:44 Oleg Nesterov
  2007-02-19 11:33 ` David Howells
  0 siblings, 1 reply; 2+ messages in thread
From: Oleg Nesterov @ 2007-02-18 21:44 UTC (permalink / raw)
  To: Andrew Morton, Venkatesh Pallipadi, Jun Nakajima
  Cc: David Howells, linux-kernel

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 <oleg@tv-sign.ru>

--- 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);
 }


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [PATCH 2/3] cpufreq_ondemand.c: don't use _WORK_NAR
  2007-02-18 21:44 [PATCH 2/3] cpufreq_ondemand.c: don't use _WORK_NAR Oleg Nesterov
@ 2007-02-19 11:33 ` David Howells
  0 siblings, 0 replies; 2+ messages in thread
From: David Howells @ 2007-02-19 11:33 UTC (permalink / raw)
  To: Oleg Nesterov
  Cc: Andrew Morton, Venkatesh Pallipadi, Jun Nakajima, linux-kernel

Oleg Nesterov <oleg@tv-sign.ru> 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 <dhowells@redhat.com>

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2007-02-19 11:34 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-02-18 21:44 [PATCH 2/3] cpufreq_ondemand.c: don't use _WORK_NAR Oleg Nesterov
2007-02-19 11:33 ` David Howells

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.