more robust halt_light

-----Original Message-----
From: [email protected] [mailto:linux-ia64- [email protected]] On Behalf Of Alex Williamson
Sent: Wednesday, March 03, 2004 9:57 AM
To: [email protected]
Subject: [PATCH] more robust halt_light

This patch adds some i386-ish enable/disable features to the
pal_halt_light cpu idle implementation as well as tries to avoid bad interactions with certain revs of PAL on McKinley cpus. Hopefully this will provide enough flexibility that we can leave it configured on in the kernel by default. My latest measurements on a 1.3GHz rx2600 show that enabling pal_halt_light in the cpu_idle routine saves 23W/cpu on

idle system.

FWIW, I added the enable/disable_hlt routines. I don't see any
consumers of this for ia64 now, but it looked useful. Patch against latest linux-2.5 bk. Thanks,

Alex

--
Alex Williamson HP Linux & Open Source Lab

=== arch/ia64/kernel/process.c 1.51 vs edited ==>--- 1.51/arch/ia64/kernel/process.c Sat Feb 28 03:02:47 2004
+++ edited/arch/ia64/kernel/process.c Wed Mar 3 09:12:44 2004

(quoted diff) +16 -0

@@ -39,6 +39,8 @@
 
 #include "sigframe.h"
 
+int hlt_counter;
+
 void (*ia64_mark_idle)(int);
 
 

@@ -159,6 +161,20 @@
 		ia64_do_signal(oldset, scr, in_syscall);
 }
 
+void disable_hlt(void)
+{
+	hlt_counter++;
+}
+
+EXPORT_SYMBOL(disable_hlt);
+
+void enable_hlt(void)
+{
+	hlt_counter--;
+}
+
+EXPORT_SYMBOL(enable_hlt);
+
 /*
 * We use this if we don't have any better idle routine..
 */

(quoted diff) +0 -0

 		safe_halt();
 #endif
 }

=== arch/ia64/kernel/setup.c 1.68 vs edited ==>--- 1.68/arch/ia64/kernel/setup.c Mon Jan 19 16:38:10 2004
+++ edited/arch/ia64/kernel/setup.c Wed Mar 3 09:12:45 2004

(quoted diff) +0 -0

@@ -76,6 +76,10 @@
 

unsigned char aux_device_present = 0xaa; /* XXX remove this

legacy I/O is gone */

(quoted diff) +4 -0

+#ifdef CONFIG_IA64_PAL_IDLE
+static unsigned char nohlt;
+#endif
+

/*
* The merge_mask variable needs to be set to

- 1). This
* mask specifies a mask of address bits that must be 0 in order for

(quoted diff) +8 -1

 */
+#ifdef CONFIG_IA64_PAL_IDLE
+		   "halt works : %s\n"
+#endif
 		   "cpu number : %lu\n"
 		   "cpu regs   : %u\n"
 		   "cpu MHz    : %lu.%06lu\n"
 		   "itc MHz    : %lu.%06lu\n"
 		   "BogoMIPS   : %lu.%02lu\n\n",
 		   cpunum, c->vendor, family, c->model, c->revision, c-
 >archrev,
-		   features, c->ppn, c->number,
+		   features,
+#ifdef CONFIG_IA64_PAL_IDLE
+		   c->hlt_works_ok ? "yes" : "no",
+#endif
+		   c->ppn, c->number,
 		   c->proc_freq / 1000000, c->proc_freq % 1000000,

		   c->itc_freq / 1000000, c->itc_freq % 1000000,
		   lpj*HZ/500000, (lpj*HZ/5000) % 100);

(quoted diff) +11 -0

 }
+
+#ifdef CONFIG_IA64_PAL_IDLE
+static int __init no_halt(char *s)
+{
+	local_cpu_data->hlt_works_ok = 0;
+	nohlt = 1;
+	return 1;
+}
+
+__setup("no-hlt", no_halt);
+#endif

=== include/asm-ia64/processor.h 1.56 vs edited ==>--- 1.56/include/asm-ia64/processor.h Wed Feb 25 15:46:40 2004
+++ edited/include/asm-ia64/processor.h Wed Mar 3 09:12:46 2004

(quoted diff) +3 -1

@@ -180,6 +180,9 @@
 #ifdef CONFIG_NUMA
 	struct ia64_node_data *node_data;
 #endif
+#ifdef CONFIG_IA64_PAL_IDLE
+	__u8 hlt_works_ok;
+#endif
 };
 
 DECLARE_PER_CPU(struct cpuinfo_ia64, cpu_info);
 
 
-

To unsubscribe from this list: send the line "unsubscribe linux-ia64"

the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

The issue with performance counters is only when PAL_HALT_LIGHT is enabled. It is nice to be able to use this power save feature when the performance counters are not currently/actively used system wide. Can we use the disable_hlt and enable_hlt APIs (mentioned in the patch below) in perfmon kind of tools to disable/enable PAL_HALT_LIGHT whenever the system is transitioning in and out of system wide performance monitoring. That way we don't have to have any tests for Mckinley, PAL versions etc. etc.

rohit

Quoted 6 lines

-----Original Message-----
Sent: Wednesday, March 03, 2004 9:57 AM
To: [email protected]
Subject: [PATCH] more robust halt_light

Quoted 6 lines

This patch adds some i386-ish enable/disable features to the
pal_halt_light cpu idle implementation as well as tries to avoid bad interactions with certain revs of PAL on McKinley cpus. Hopefully this will provide enough flexibility that we can leave it configured on in the kernel by default. My latest measurements on a 1.3GHz rx2600 show that enabling pal_halt_light in the cpu_idle routine saves 23W/cpu on

an

Quoted 8 lines

idle system.

FWIW, I added the enable/disable_hlt routines. I don't see any
consumers of this for ia64 now, but it looked useful. Patch against latest linux-2.5 bk. Thanks,

Alex

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line · Alex Williamson

Can we get rid of the CONFIG option too? Or do folks who care (too?) much about wake-up latency prefer to turn off a CONFIG option over booting with nohlt?

I was curious about that myself, but I thought I remembered from
Stephane that the perf counters didn't really recover from a PAL_HALT_LIGHT on McKinley.

If that's not the case, maybe we can move
the PAL check into perfmon code, and it can selectively disable it as it needs via the disable_hlt API.

I assume there are some cases were
perfmon wouldn't need to disable halt_light on working PAL, so the rev check might not go away.

Alex

Quoted 31 lines · Rohit

The issue with performance counters is only when PAL_HALT_LIGHT is enabled. It is nice to be able to use this power save feature when the performance counters are not currently/actively used system wide. Can we use the disable_hlt and enable_hlt APIs (mentioned in the patch below) in perfmon kind of tools to disable/enable PAL_HALT_LIGHT whenever the system is transitioning in and out of system wide performance monitoring. That way we don't have to have any tests for Mckinley, PAL versions etc. etc.

rohit

Quoted 6 lines

-----Original Message-----
Sent: Wednesday, March 03, 2004 9:57 AM
To: [email protected]
Subject: [PATCH] more robust halt_light

Quoted 6 lines

This patch adds some i386-ish enable/disable features to the
pal_halt_light cpu idle implementation as well as tries to avoid bad interactions with certain revs of PAL on McKinley cpus. Hopefully this will provide enough flexibility that we can leave it configured on in the kernel by default. My latest measurements on a 1.3GHz rx2600 show that enabling pal_halt_light in the cpu_idle routine saves 23W/cpu on

an

Quoted 8 lines

idle system.

FWIW, I added the enable/disable_hlt routines. I don't see any
consumers of this for ia64 now, but it looked useful. Patch against latest linux-2.5 bk. Thanks,

Alex

Signature · 6 lines

Alex Williamson                             HP Linux & Open Source Lab

-
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

-----Original Message-----
From: Jesse Barnes [mailto:[email protected]]
Sent: Wednesday, March 03, 2004 2:56 PM
To: [email protected]
Cc: Alex Williamson; Seth, Rohit; linux-ia64
Subject: Re: [PATCH] more robust halt_light

Quoted 3 lines · David Mosberger

Can we get rid of the CONFIG option too? Or do folks who care (too?) much about wake-up latency prefer to turn off a CONFIG option over booting with nohlt?

Some people have come to me concerned about the wakeup latency of

the halt call in there, and it also looks like the PAL has a bug on our platform that causes hangs when we call PAL_HALT_LIGHT (which we're tracking down), so I wouldn't mind if the config option stuck around a little longer (or was a boot time parameter at least).

Thanks,
Jesse

-----Original Message-----
From: Grant Grundler [mailto:[email protected]]
Sent: Wednesday, March 03, 2004 3:35 PM
To: Alex Williamson
Cc: Seth, Rohit; linux-ia64
Subject: Re: [PATCH] more robust halt_light

Quoted 4 lines · Alex Williamson

I was curious about that myself, but I thought I remembered from
Stephane that the perf counters didn't really recover from a PAL_HALT_LIGHT on McKinley.

The way I recall Stephane explaining it to me was the PMU was completely disabled after returning from PAL_HALT_LIGHT. ISTR no PAL fix was never released for Mckinley. And even if one was, we'd have to convince HP firmware teams to roll and qualify it. Unlikely.

Quoted 3 lines · David Mosberger

Can we get rid of the CONFIG option too? Or do folks who care (too?) much about wake-up latency prefer to turn off a CONFIG option over booting with nohlt?

Some people have come to me concerned about the wakeup latency of having the halt call in there, and it also looks like the PAL has a bug on our platform that causes hangs when we call PAL_HALT_LIGHT (which we're tracking down), so I wouldn't mind if the config option stuck around a little longer (or was a boot time parameter at least).

As far as latency is concerned, do you have any specific workload that is getting impacted (severly) by this transition.

I think we should remove the compile time CONFIG_OPTION for PAL_HALT_LIGHT. And instead use /proc interface to dynamically enable/disable the power transition.

Perhaps sn specific code (maybe sn_setup) could call disable_hlt() until you're comfortable leaving it on by default. Requiring a boot time command like option on your platform sounds error prone.