linux.kernel - 26 new messages in 21 topics - digest

linux.kernel
http://groups.google.com/group/linux.kernel?hl=en

linux.kernel@googlegroups.com

Today's topics:

* last minute md fixes for 3.13 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/009da8d9e46d4cb1?hl=en
* timers: Reduce future __run_timers() latency for first add to empty list - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/9be12def62cea4b8?hl=en
* x86 idle: restore mwait_idle() - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/4173ff2d30e48dc0?hl=en
* linux-next: manual merge of the md tree with the block tree - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/39bfb73962293476?hl=en
* sched: find the latest idle cpu - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/c0d098923e6f4ee6?hl=en
* clk: sirf: re-arch to make the codes support both prima2 and atlas6 - 2
messages, 2 authors
http://groups.google.com/group/linux.kernel/t/59c5ccff471f63ec?hl=en
* perf tools: Synthesize anon MMAP records on the heap - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/6f9d2914689266fc?hl=en
* mm/zswap: add writethrough option - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/83507199cf42b4fb?hl=en
* Documentation / CPU hotplug: Fix the typo in example code - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/6b7da4e88453a321?hl=en
* perf tools: Do proper comm override error handling - 3 messages, 1 author
http://groups.google.com/group/linux.kernel/t/fbde0854e39b253b?hl=en
* ARM: dts: imx28-apf28dev: add user button - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/37e56edb632b56d0?hl=en
* mm: keep page cache radix tree nodes in check - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/8cc6f8a99500ab70?hl=en
* toshiba_acpi: Support RFKILL hotkey scancode - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/1b11c89d07d2b5c6?hl=en
* ACPI/Battery: Add a _BIX quirk for NEC LZ750/LS - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/eb56e9827c8b75a7?hl=en
* x86, cpu, amd: Add workaround for family 16h, erratum 793 - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/0e4150592fc82fa1?hl=en
* sched_clock: Disable seqlock lockdep usage in sched_clock() - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/319d06ce78cc6f61?hl=en
* x86, apic, kexec, Documentation: Add disable_cpu_apicid kernel parameter - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/5b85673fa2d0f550?hl=en
* crypto:s5p-sss: validate iv before memcpy - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/7c2633b6acc77c1b?hl=en
* clockevents/clocksources: 3.13 fixes - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/4bceba4e38fac341?hl=en
* x86: intel-mid: sfi_handle_*_dev() should check for pdata error code - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/33ee917d7e436dbc?hl=en
* [PATCH 1/9] mm: slab/slub: use page->list consistently instead of page->lru -
1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/acdb506b6b3ca796?hl=en

==============================================================================
TOPIC: last minute md fixes for 3.13
http://groups.google.com/group/linux.kernel/t/009da8d9e46d4cb1?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 14 2014 9:30 pm
From: NeilBrown



Sorry they are late .... Christmas holidays and all that. Hopefully they can
still squeak into 3.13.

NeilBrown


The following changes since commit 6d183de4077191d1201283a9035ce57a9b05254d:

md/raid5: fix newly-broken locking in get_active_stripe. (2013-11-28 11:00:15 +1100)

are available in the git repository at:

git://neil.brown.name/md tags/md/3.13-fixes

for you to fetch changes up to 8313b8e57f55b15e5b7f7fc5d1630bbf686a9a97:

md: fix problem when adding device to read-only array with bitmap. (2014-01-14 16:44:08 +1100)

----------------------------------------------------------------
md: half a dozen bug fixes for 3.13

All of these fix real bugs the people have hit, and are tagged
for -stable.

----------------------------------------------------------------
NeilBrown (6):
md/raid5: Fix possible confusion when multiple write errors occur.
md/raid10: fix two bugs in handling of known-bad-blocks.
md/raid1: fix request counting bug in new 'barrier' code.
md/raid5: fix a recently broken BUG_ON().
md/raid10: fix bug when raid10 recovery fails to recover a block.
md: fix problem when adding device to read-only array with bitmap.

drivers/md/md.c | 18 +++++++++++++++---
drivers/md/md.h | 3 +++
drivers/md/raid1.c | 3 +--
drivers/md/raid10.c | 12 ++++++------
drivers/md/raid5.c | 7 ++++---
5 files changed, 29 insertions(+), 14 deletions(-)





==============================================================================
TOPIC: timers: Reduce future __run_timers() latency for first add to empty
list
http://groups.google.com/group/linux.kernel/t/9be12def62cea4b8?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 14 2014 9:30 pm
From: "Paul E. McKenney"


From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>

The __run_timers() function currently steps through the list one jiffy at
a time in order to update the timer wheel. However, if the timer wheel
is empty, no adjustment is needed other than updating ->timer_jiffies.
Therefore, just before we add a timer to an empty timer wheel, we should
mark the timer wheel as being up to date. This marking will reduce (and
perhaps eliminate) the jiffy-stepping that a future __run_timers() call
will need to do in response to some future timer posting or migration.
This commit therefore updates ->timer_jiffies for this case.

Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
---
kernel/timer.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/kernel/timer.c b/kernel/timer.c
index bdd1c00ec4ec..b49d2d0e879e 100644
--- a/kernel/timer.c
+++ b/kernel/timer.c
@@ -749,6 +749,7 @@ __mod_timer(struct timer_list *timer, unsigned long expires,

base = lock_timer_base(timer, &flags);

+ (void)catchup_timer_jiffies(base);
ret = detach_if_pending(timer, base, false);
if (!ret && pending_only)
goto out_unlock;
--
1.8.1.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: x86 idle: restore mwait_idle()
http://groups.google.com/group/linux.kernel/t/4173ff2d30e48dc0?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 14 2014 9:40 pm
From: Len Brown


From: Len Brown <len.brown@intel.com>

In Linux-3.9 we removed the mwait_idle() loop:
'x86 idle: remove mwait_idle() and "idle=mwait" cmdline param'
(69fb3676df3329a7142803bb3502fa59dc0db2e3)

The reasoning was that modern machines should be sufficiently
happy during the boot process using the default_idle() HALT loop,
until cpuidle loads and either acpi_idle or intel_idle
invoke the newer MWAIT-with-hints idle loop.

But two machines reported problems:
1. Certain Core2-era machines support MWAIT-C1 and HALT only.
MWAIT-C1 is preferred for optimal power and performance.
But if they support just C1, cpuidle never loads and
so they use the boot-time default idle loop forever.

2. Some laptops will boot-hang if HALT is used,
but will boot successfully if MWAIT is used.
This appears to be a hidden assumption in BIOS SMI,
that is presumably valid on the proprietary OS
where the BIOS was validated.

https://bugzilla.kernel.org/show_bug.cgi?id=60770

So here we effectively revert the patch above, restoring
the mwait_idle() loop. However, we don't bother restoring
the idle=mwait cmdline parameter, since it appears to add
no value.

Maintainer notes:
For 3.9, simply revert 69fb3676df
for 3.10, patch -F3 applies, fuzz needed due to __cpuinit use in context
For 3.11, 3.12, 3.13, this patch applies cleanly

Cc: Mike Galbraith <bitbucket@online.de>
Cc: Ian Malone <ibmalone@gmail.com>
Cc: Josh Boyer <jwboyer@redhat.com>
Cc: <stable@vger.kernel.org> # 3.9, 3.10, 3.11, 3.12, 3.13
Signed-off-by: Len Brown <len.brown@intel.com>
---
arch/x86/kernel/process.c | 46 ++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 46 insertions(+)

diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 3fb8d95..db471a8 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -398,6 +398,49 @@ static void amd_e400_idle(void)
default_idle();
}

+/*
+ * Intel Core2 and older machines prefer MWAIT over HALT for C1.
+ * We can't rely on cpuidle installing MWAIT, because it will not load
+ * on systems that support only C1 -- so the boot default must be MWAIT.
+ *
+ * Some AMD machines are the opposite, they depend on using HALT.
+ *
+ * So for default C1, which is used during boot until cpuidle loads,
+ * use MWAIT-C1 on Intel HW that has it, else use HALT.
+ */
+static int prefer_mwait_c1_over_halt(const struct cpuinfo_x86 *c)
+{
+ if (c->x86_vendor != X86_VENDOR_INTEL)
+ return 0;
+
+ if (!cpu_has(c, X86_FEATURE_MWAIT))
+ return 0;
+
+ return 1;
+}
+
+/*
+ * MONITOR/MWAIT with no hints, used for default default C1 state.
+ * This invokes MWAIT with interrutps enabled and no flags,
+ * which is backwards compatible with the original MWAIT implementation.
+ */
+
+static void mwait_idle(void)
+{
+ if (!need_resched()) {
+ if (this_cpu_has(X86_FEATURE_CLFLUSH_MONITOR))
+ clflush((void *)&current_thread_info()->flags);
+
+ __monitor((void *)&current_thread_info()->flags, 0, 0);
+ smp_mb();
+ if (!need_resched())
+ __sti_mwait(0, 0);
+ else
+ local_irq_enable();
+ } else
+ local_irq_enable();
+}
+
void select_idle_routine(const struct cpuinfo_x86 *c)
{
#ifdef CONFIG_SMP
@@ -411,6 +454,9 @@ void select_idle_routine(const struct cpuinfo_x86 *c)
/* E400: APIC timer interrupt does not wake up CPU from C1e */
pr_info("using AMD E400 aware idle routine\n");
x86_idle = amd_e400_idle;
+ } else if (prefer_mwait_c1_over_halt(c)) {
+ pr_info("using mwait in idle threads\n");
+ x86_idle = mwait_idle;
} else
x86_idle = default_idle;
}
--
1.8.5.2.309.ga25014b

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: linux-next: manual merge of the md tree with the block tree
http://groups.google.com/group/linux.kernel/t/39bfb73962293476?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 14 2014 9:40 pm
From: NeilBrown


On Wed, 15 Jan 2014 15:07:43 +1100 Stephen Rothwell <sfr@canb.auug.org.au>
wrote:

> Hi Neil,
>
> Today's linux-next merge of the md tree got a conflict in
> drivers/md/raid10.c between commit 4f024f3797c4 ("block: Abstract out
> bvec iterator") from the block tree and commit b50c259e25d9 ("md/raid10:
> fix two bugs in handling of known-bad-blocks") from the md tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
>

Thanks Stephen.
Those md fixes are now on their way to Linus (I'm hoping for 3.13 inclusion,
I might be lucky). Good they they are easy to resolve!

Thanks,
NeilBrown





==============================================================================
TOPIC: sched: find the latest idle cpu
http://groups.google.com/group/linux.kernel/t/c0d098923e6f4ee6?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Jan 14 2014 9:40 pm
From: Michael wang


On 01/15/2014 12:07 PM, Alex Shi wrote:
> Currently we just try to find least load cpu. If some cpus idled,
> we just pick the first cpu in cpu mask.
>
> In fact we can get the interrupted idle cpu or the latest idled cpu,
> then we may get the benefit from both latency and power.
> The selected cpu maybe not the best, since other cpu may be interrupted
> during our selecting. But be captious costs too much.

So the idea here is we want to choose the latest idle cpu if we have
multiple idle cpu for choosing, correct?

And I guess that was in order to avoid choosing tickless cpu while there
are un-tickless idle one, is that right?

What confused me is, what about those cpu who just going to recover from
tickless as you mentioned, which means latest idle doesn't mean the best
choice, or even could be the worst (if just two choice, and the longer
tickless one is just going to recover while the latest is going to
tickless).

So what about just check 'ts->tick_stopped' and record one ticking idle
cpu? the cost could be lower than time comparison, we could reduce the
risk may be...(well, not so risky since the logical only works when
system is relaxing with several cpu idle)

Regards,
Michael Wang

>
> Signed-off-by: Alex Shi <alex.shi@linaro.org>
> ---
> kernel/sched/fair.c | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index c7395d9..fb52d26 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -4167,6 +4167,26 @@ find_idlest_cpu(struct sched_group *group, struct task_struct *p, int this_cpu)
> min_load = load;
> idlest = i;
> }
> +#ifdef CONFIG_NO_HZ_COMMON
> + /*
> + * Coarsely to get the latest idle cpu for shorter latency and
> + * possible power benefit.
> + */
> + if (!min_load) {
> + struct tick_sched *ts = &per_cpu(tick_cpu_sched, i);
> +
> + s64 latest_wake = 0;
> + /* idle cpu doing irq */
> + if (ts->inidle && !ts->idle_active)
> + idlest = i;
> + /* the cpu resched */
> + else if (!ts->inidle)
> + idlest = i;
> + /* find latest idle cpu */
> + else if (ktime_to_us(ts->idle_entrytime) > latest_wake)
> + idlest = i;
> + }
> +