| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20091110034831.GB26809@elte.hu>
Date: Tue, 10 Nov 2009 04:48:31 +0100
From: Ingo Molnar <mingo@...e.hu>
To: Greg KH <gregkh@...e.de>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Chris Wright <chrisw@...s-sol.org>
Cc: linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
"H. Peter Anvin" <hpa@...or.com>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: [RFC] new -stable tag variant, Git workflow question
FYI, today i committed a scheduler performance fix that has a number of
commit prerequisites for -stable integration. Those commits are not
marked -stable.
Previously, in similar situations, i solved it by email-forwarding the
prereq commits to stable@...nel.org. (or by waiting for your 'it does
not apply to -stable' email and figuring out the prereqs then.)
But we can move this into the Git commit space too, and minimize the
work for the -stable team, via a new -stable tag variant. So with this
new commit i started using a new tagging scheme in the commit itself:
Cc: <stable@...nel.org> # .32.x: a1f84a3: sched: Check for an idle shared cache
Cc: <stable@...nel.org> # .32.x: 1b9508f: sched: Rate-limit newidle
Cc: <stable@...nel.org> # .32.x: fd21073: sched: Fix affinity logic
Cc: <stable@...nel.org> # .32.x
LKML-Reference: <1257821402.5648.17.camel@...ge.simson.net>
Signed-off-by: Ingo Molnar <mingo@...e.hu>
The tag sequence has the meaning of:
git cherry-pick a1f84a3
git cherry-pick 1b9508f
git cherry-pick fd21073
git cherry-pick <this commit>
and i'm wondering whether this tagging scheme is fine with your -stable
scripting, etc.
A further question is, i can see using this tagging scheme in the future
in merge commits log messages too - will your scripts notice that too?
For example if there's a few commits left in tip:*/urgent branches
(tip:sched/urgent, tip:core/urgent, tip:x86/urgent, etc.) by the time
v2.6.32 is released, i will then merge them into tip:sched/core,
tip:core/core, tip:x86/core, etc. - and i could use the merge commit as
a notification area to 'activate' them for -stable backporting via a
merge commit.
This is how such merge commits would look like:
Merge branch 'core/urgent' into core/rcu
Merge reason: Pick up urgent fixes that did not make it into .32.0
Cc: <stable@...nel.org> # .32.x: 83f5b01: rcu: Fix long-grace-period race
Signed-off-by: Ingo Molnar <mingo@...e.hu>
This is not so rare of a situation as it might seem - for the trees i
maintain it happens in almost every release cycle - i typically skip
urgent branch merges after -rc8/-rc9, unless they are very-very-urgent
fixes - but they'd still be eligible for -stable.
I've attached the full commit below. The prereq commits are not uptream
yet, and they dont carry a -stable backporting tag as the -stable
relevance was not anticipated at that point yet. They will all be
upstream in the next merge window when Linus merges the relevant tree -
and then all these tags become visible to the -stable team's scripts.
What do you think about this new -stable tagging variant? To me it looks
quite intuitive, less error-prone and it is more informative as well.
Furthermore, it gives us some freedom to mark commits as backport
candidates later on. I kept them oneliners for the purpose of making
them all self-sufficient tags.
( Sidenote: i wouldnt go as far as to generate null Git commits to mark
backports after the fact - this scheme is for a series of commits that
get 'completed' - there's usually a final followup commit that can
embedd this information. )
Ingo
---------------------------->
>From eae0c9dfb534cb3449888b9601228efa6480fdb5 Mon Sep 17 00:00:00 2001
From: Mike Galbraith <efault@....de>
Date: Tue, 10 Nov 2009 03:50:02 +0100
Subject: [PATCH] sched: Fix and clean up rate-limit newidle code
Commit 1b9508f, "Rate-limit newidle" has been confirmed to fix
the netperf UDP loopback regression reported by Alex Shi.
This is a cleanup and a fix:
- moved to a more out of the way spot
- fix to ensure that balancing doesn't try to balance
runqueues which haven't gone online yet, which can
mess up CPU enumeration during boot.
Reported-by: Alex Shi <alex.shi@...el.com>
Reported-by: Zhang, Yanmin <yanmin_zhang@...ux.intel.com>
Signed-off-by: Mike Galbraith <efault@....de>
Acked-by: Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc: <stable@...nel.org> # .32.x: a1f84a3: sched: Check for an idle shared cache
Cc: <stable@...nel.org> # .32.x: 1b9508f: sched: Rate-limit newidle
Cc: <stable@...nel.org> # .32.x: fd21073: sched: Fix affinity logic
Cc: <stable@...nel.org> # .32.x
LKML-Reference: <1257821402.5648.17.camel@...ge.simson.net>
Signed-off-by: Ingo Molnar <mingo@...e.hu>
---
kernel/sched.c | 28 +++++++++++++++-------------
1 files changed, 15 insertions(+), 13 deletions(-)
diff --git a/kernel/sched.c b/kernel/sched.c
index 23e3535..ad37776 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -2354,17 +2354,6 @@ static int try_to_wake_up(struct task_struct *p, unsigned int state,
if (rq != orig_rq)
update_rq_clock(rq);
- if (rq->idle_stamp) {
- u64 delta = rq->clock - rq->idle_stamp;
- u64 max = 2*sysctl_sched_migration_cost;
-
- if (delta > max)
- rq->avg_idle = max;
- else
- update_avg(&rq->avg_idle, delta);
- rq->idle_stamp = 0;
- }
-
WARN_ON(p->state != TASK_WAKING);
cpu = task_cpu(p);
@@ -2421,6 +2410,17 @@ out_running:
#ifdef CONFIG_SMP
if (p->sched_class->task_wake_up)
p->sched_class->task_wake_up(rq, p);
+
+ if (unlikely(rq->idle_stamp)) {
+ u64 delta = rq->clock - rq->idle_stamp;
+ u64 max = 2*sysctl_sched_migration_cost;
+
+ if (delta > max)
+ rq->avg_idle = max;
+ else
+ update_avg(&rq->avg_idle, delta);
+ rq->idle_stamp = 0;
+ }
#endif
out:
task_rq_unlock(rq, &flags);
@@ -4098,7 +4098,7 @@ static int load_balance(int this_cpu, struct rq *this_rq,
unsigned long flags;
struct cpumask *cpus = __get_cpu_var(load_balance_tmpmask);
- cpumask_setall(cpus);
+ cpumask_copy(cpus, cpu_online_mask);
/*
* When power savings policy is enabled for the parent domain, idle
@@ -4261,7 +4261,7 @@ load_balance_newidle(int this_cpu, struct rq *this_rq, struct sched_domain *sd)
int all_pinned = 0;
struct cpumask *cpus = __get_cpu_var(load_balance_tmpmask);
- cpumask_setall(cpus);
+ cpumask_copy(cpus, cpu_online_mask);
/*
* When power savings policy is enabled for the parent domain, idle
@@ -9522,6 +9522,8 @@ void __init sched_init(void)
rq->cpu = i;
rq->online = 0;
rq->migration_thread = NULL;
+ rq->idle_stamp = 0;
+ rq->avg_idle = 2*sysctl_sched_migration_cost;
INIT_LIST_HEAD(&rq->migration_queue);
rq_attach_root(rq, &def_root_domain);
#endif
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists