Re: [git pull] scheduler/misc fixes

From: David Miller
Date: Thu Apr 24 2008 - 23:46:30 EST


From: Ingo Molnar <mingo@xxxxxxx>
Date: Fri, 25 Apr 2008 00:55:30 +0200

>
> Linus, please pull the latest scheduler/misc fixes git tree from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched-fixes.git for-linus
>
> a scheduler fix, a (long-standing) seqlock fix and a softlockup+nohz
> fix.

Correction, the softlock+nohz patch here doesn't actually fix the
reported regression. It fixes some other theoretical bug you
discovered while trying to fix the regression reports.

Ingo, you've known exactly which changeset adds the regression for
more than 4 days now.

It's a small changeset, and you have no idea what the problem is. The
changeset in question is labelled as a bug fix, but it's pointless for
it to be there if it adds problems too.

Please revert this change until you understand the problem better.
Please! I even gave Peter Z. access to my Niagara2 system, so you can
ask him to help you figure out the reason for all of these softlockup
regressions added by the sched merge 4 days ago.

Please also add the trivial regression fix I posted to you earlier,
included again below, you seem to be selectively reading email from me
and missing bug fix patches in the process.

sched: Use alloc_bootmem() instead of alloc_bootmem_low()

There is no guarentee that there is physical ram below 4GB, and in
fact many boxes don't have exactly that.

Signed-off-by: David S. Miller <davem@xxxxxxxxxxxxx>

diff --git a/kernel/sched.c b/kernel/sched.c
index 0014b03..09ca69b 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -8128,7 +8128,7 @@ void __init sched_init(void)
* we use alloc_bootmem().
*/
if (alloc_size) {
- ptr = (unsigned long)alloc_bootmem_low(alloc_size);
+ ptr = (unsigned long)alloc_bootmem(alloc_size);

#ifdef CONFIG_FAIR_GROUP_SCHED
init_task_group.se = (struct sched_entity **)ptr;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/