Hi Morten,
I have just read your scheduler slide in LCA2014, and have some questions
which want to confirm with you. Before that, I shall say it is an
impressive slide
that well state the importance why scheduler change would benefit the power.
As you may also know the data from ARM's spec for A15/A7 power/performance diff:
http://www.arm.com/files/downloads/big.LITTLE_Final.pdf
It shows one fact that even over one cpu, different tasks would shows different
performance and power difference, as I see the programs like Dhrystone/FDCT
shows different performance growth over A7 when running over A15.
So is it ok to get the cpu's power only by its current usage, like busy ratio?
And don't care for its running task's type?
I am not sure whether this is what your meaning presented in the slide.
That is to modeling the energy diff, and move task around if shows
energy benefit.
Is there any possible to also add task type impact into scheduler design?
Thanks,
Lei
Ideally, .driver_data field of struct cpufreq_frequency_table must not be used
by core at all. But during a recent change if its value is same as
CPUFREQ_BOOST_FREQ macro, then it is treated specially by core.
The value of this macro was set to ~2 earlier, i.e. 0xFFFFFFFD. In case some
driver is using this field for its own data and sets this field to -3, then with
two's complement that value will also become 0xFFFFFFFD.
To fix this issue, lets change value of this flag to a very uncommon value which
shouldn't be used by any driver unless they want to use BOOST feature.
Along with this update comments to make this more clear.
Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org>
---
Gautham/Vaidy: I hope this fixes the problem we discussed for your patchset.
include/linux/cpufreq.h | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index c48e595..9f25d9d 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -455,12 +455,18 @@ extern struct cpufreq_governor cpufreq_gov_conservative;
* FREQUENCY TABLE HELPERS *
*********************************************************************/
+/* Special Values of .frequency field */
#define CPUFREQ_ENTRY_INVALID ~0
#define CPUFREQ_TABLE_END ~1
-#define CPUFREQ_BOOST_FREQ ~2
+/* Special Values of .driver_data field */
+#define CPUFREQ_BOOST_FREQ 0xABABABAB
struct cpufreq_frequency_table {
- unsigned int driver_data; /* driver specific data, not used by core */
+ /*
+ * driver specific data, not used by core unless it is set to
+ * CPUFREQ_BOOST_FREQ.
+ */
+ unsigned int driver_data;
unsigned int frequency; /* kHz - doesn't need to be in ascending
* order */
};
--
1.7.12.rc2.18.g61b472e
The mux driver is anomalous among all the serial drivers that can
define SUPPORT_SYSRQ because it can, with some configs, set
SUPPORT_SYSRQ when SERIAL_CORE_CONSOLE is not set.
Not only does this impose a pointless (but tiny) runtime overhead for
such configs but, more significantly, it adds needless complexity when
doing a code review to check for unexpected side effects of any
changes to the serial core.
This is (cross-)compile tested only because I do not have any PA-RISC
hardware.
Signed-off-by: Daniel Thompson <daniel.thompson(a)linaro.org>
---
drivers/tty/serial/mux.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/mux.c b/drivers/tty/serial/mux.c
index 7fd6aaa..9b27d34 100644
--- a/drivers/tty/serial/mux.c
+++ b/drivers/tty/serial/mux.c
@@ -29,7 +29,7 @@
#include <asm/irq.h>
#include <asm/parisc-device.h>
-#ifdef CONFIG_MAGIC_SYSRQ
+#if defined(CONFIG_SERIAL_MUX_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ)
#include <linux/sysrq.h>
#define SUPPORT_SYSRQ
#endif
--
1.9.0
This driver, like several others, uses the upper bits of the character
to track both real and dummy state. Unfortunately it neglects to mask
these bits properly when passing the character data around. This means
neither break detection nor sysrq character handling work correctly.
This patch adds the requires masking and has been tested to confirm
that it correctly handles magic sysrq sequences on ST's B2020 board.
Signed-off-by: Daniel Thompson <daniel.thompson(a)linaro.org>
---
drivers/tty/serial/st-asc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/st-asc.c b/drivers/tty/serial/st-asc.c
index 21e6e84..dd3a96e 100644
--- a/drivers/tty/serial/st-asc.c
+++ b/drivers/tty/serial/st-asc.c
@@ -295,7 +295,7 @@ static void asc_receive_chars(struct uart_port *port)
status & ASC_STA_OE) {
if (c & ASC_RXBUF_FE) {
- if (c == ASC_RXBUF_FE) {
+ if (c == (ASC_RXBUF_FE | ASC_RXBUF_DUMMY_RX)) {
port->icount.brk++;
if (uart_handle_break(port))
continue;
@@ -325,7 +325,7 @@ static void asc_receive_chars(struct uart_port *port)
flag = TTY_FRAME;
}
- if (uart_handle_sysrq_char(port, c))
+ if (uart_handle_sysrq_char(port, c & 0xff))
continue;
uart_insert_char(port, c, ASC_RXBUF_DUMMY_OE, c & 0xff, flag);
--
1.9.0
This driver, like several others, uses the upper bits of the character
to track both real and dummy state. Unfortunately it neglects to mask
these bits properly when passing the character data around. This means
neither break detection nor sysrq character handling work correctly.
This patch adds the requires masking and has been tested to confirm
that it correctly handles magic sysrq sequences on ST's B2020 board.
Signed-off-by: Daniel Thompson <daniel.thompson(a)linaro.org>
---
drivers/tty/serial/st-asc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/st-asc.c b/drivers/tty/serial/st-asc.c
index 21e6e84..dd3a96e 100644
--- a/drivers/tty/serial/st-asc.c
+++ b/drivers/tty/serial/st-asc.c
@@ -295,7 +295,7 @@ static void asc_receive_chars(struct uart_port *port)
status & ASC_STA_OE) {
if (c & ASC_RXBUF_FE) {
- if (c == ASC_RXBUF_FE) {
+ if (c == (ASC_RXBUF_FE | ASC_RXBUF_DUMMY_RX)) {
port->icount.brk++;
if (uart_handle_break(port))
continue;
@@ -325,7 +325,7 @@ static void asc_receive_chars(struct uart_port *port)
flag = TTY_FRAME;
}
- if (uart_handle_sysrq_char(port, c))
+ if (uart_handle_sysrq_char(port, c & 0xff))
continue;
uart_insert_char(port, c, ASC_RXBUF_DUMMY_OE, c & 0xff, flag);
--
1.9.0
CPUFreq core doesn't control value of .driver_data and this field is completely
driver specific. This can contain any value and not only indexes. For most of
the drivers, which aren't using this field, its value is zero. So, printing this
from core doesn't make any sense. Don't print it.
Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org>
---
drivers/cpufreq/freq_table.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/cpufreq/freq_table.c b/drivers/cpufreq/freq_table.c
index 8e54f97..f002272 100644
--- a/drivers/cpufreq/freq_table.c
+++ b/drivers/cpufreq/freq_table.c
@@ -36,8 +36,7 @@ int cpufreq_frequency_table_cpuinfo(struct cpufreq_policy *policy,
&& table[i].driver_data == CPUFREQ_BOOST_FREQ)
continue;
- pr_debug("table entry %u: %u kHz, %u driver_data\n",
- i, freq, table[i].driver_data);
+ pr_debug("table entry %u: %u kHz\n", i, freq);
if (freq < min_freq)
min_freq = freq;
if (freq > max_freq)
@@ -175,8 +174,8 @@ int cpufreq_frequency_table_target(struct cpufreq_policy *policy,
} else
*index = optimal.driver_data;
- pr_debug("target is %u (%u kHz, %u)\n", *index, table[*index].frequency,
- table[*index].driver_data);
+ pr_debug("target index is %u, freq is:%u kHz\n", *index,
+ table[*index].frequency);
return 0;
}
--
1.7.12.rc2.18.g61b472e