Re: [BUG] sched: big numa dynamic sched domain memory corruption
From: Paul Jackson
Date: Wed Aug 02 2006 - 02:56:19 EST
> Basically SLES10 has to backport all these patches:
> sched: fix group power for allnodes_domains
> sched_domai: Allocate sched_group structures dynamically
> sched: build_sched_domains() fix
A few questions on this, centered around the question of which dynamic
sched domain patches we should backport to SLES10.
Readers not seriously interested in sched domains on 2.6.16.* kernels
will probably want to ignore this post.
Is the first of the above three patches the one needed to fix the "big
numa dynamic sched domain memory corruption" that started off this
thread? I'd test that theory now, but someone else is using my test
The second of these three, "Allocate sched_group structures
dynamically," doesn't apply cleanly, because it depends on the
free_sched_groups() code added in another patch:
This patch in turn seems to have some important fixes and followups
in a couple other patches, listed below ...
Which of the following would you recommend I advise SUSE do for SLES10:
1) Backport the "Allocate sched_group structures dynamically"
patch (removing the free_sched_groups() related pieces, and
changing the "goto error" statements back to "break"), staying
with just your above recommended set of three patches, or
2) Also take the sched_domain-handle-kmalloc-failure.patch and its
immediate followups, resulting in the following patch set:
3) Just take the first patch in this set, as it (I'm guessing) is
the one needed to fix the immediate problem -- the memory
Cetainly the patchset in (2) applies more cleanly than (1), and it sure
seems to me like all these patches are fixing things we would want to
fix in SLES10.
Was there a reason you did not include these additional patches in your
recommendations for patches to backport to SLES10?
Any other patches I really should consider? If so, why?
If you recommend (2), then can you offer a clean description of bug(s)
fixed, including symptoms and potential severity, and how fixed, for
each of the patches in that proposed patchset? SUSE won't be much
interested in fixes unless they have a clear description of the pain
they will encounter if they don't take the fix. The existing patch
header comments don't particularly spell that out. They say what
changed, but not much of the why nor what kind of hurt one is in
without the change.
Also do you have any way to test whichever patch set you recommend on
other systems? I can test on my big honkin numa iron (100's of CPUs,
NUMA yes, SMT no, MC no), but SUSE will want to know that this stuff
worked on more ordinary systems and SMT (hyperthread) and MC
Sorry for all the questions ...
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@xxxxxxx> 1.925.600.0401
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/