On Wed, Aug 24, 2005 at 01:31:07PM -0700, Paul Jackson wrote:
> ==========
>
> The safest, mind numbingly simple thing to do that would avoid the oops
> that Hawkes reported is to simply not have the cpuset code call the
> code to setup a dynamic sched domain. This is choice (2) above, and
> could be done at the last hour with relative safety.
>
> Here is an untested patch that does (2):
>
> =====
>
> Index: linux-2.6.13-cpuset-mempolicy-migrate/kernel/cpuset.c
> ===================================================================
> --- linux-2.6.13-cpuset-mempolicy-migrate.orig/kernel/cpuset.c
> +++ linux-2.6.13-cpuset-mempolicy-migrate/kernel/cpuset.c
> @@ -627,6 +627,15 @@ static int validate_change(const struct
> * Call with cpuset_sem held. May nest a call to the
> * lock_cpu_hotplug()/unlock_cpu_hotplug() pair.
> */
> +
> +/*
> + * Hack to avoid 2.6.13 partial node dynamic sched domain bug.
> + * Disable letting 'cpu_exclusive' cpusets define dynamic sched
> + * domains, until the sched domain can handle partial nodes.
> + * Remove this ifdef hackery when sched domains fixed.
> + */
> +#define DISABLE_EXCLUSIVE_CPU_DOMAINS 1
> +#ifdef DISABLE_EXCLUSIVE_CPU_DOMAINS
> static void update_cpu_domains(struct cpuset *cur)
> {
> struct cpuset *c, *par = cur->parent;
> @@ -667,6 +676,11 @@ static void update_cpu_domains(struct cp
> partition_sched_domains(&pspan, &cspan);
> unlock_cpu_hotplug();
> }
> +#else
> +static void update_cpu_domains(struct cpuset *cur)
> +{
> +}
> +#endif
>
> static int update_cpumask(struct cpuset *cs, char *buf)
> {
>
>
> =====
>
I'll ack this for now until I fix the problems that I am seeing
on ppc64
Acked-by: Dinakar Guniguntala <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
