Re: [BUG] sched: big numa dynamic sched domain memory corruption

[Paul Jackson]

Suresh wrote:
> 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
machine tonight.

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:

  sched_domain-handle-kmalloc-failure.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:

	sched-fix-group-power-for-allnodes_domains.patch
	sched_domain-handle-kmalloc-failure.patch
	sched_domain-handle-kmalloc-failure-fix.patch
	sched_domain-dont-use-gfp_atomic.patch
	sched_domain-use-kmalloc_node.patch
	sched_domain-allocate-sched_group-structures-dynamically.patch
	sched-build_sched_domains-fix.patch

 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
    corruption.


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
(multicore) systems.

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/