[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070322223945.GA22206@sgi.com>
Date: Thu, 22 Mar 2007 16:39:45 -0600
From: Cliff Wickman <cpw@....com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: dino@...ibm.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] cpusets/sched_domain reconciliation
Hello Andrew,
On Thu, Mar 22, 2007 at 02:21:52PM -0700, Andrew Morton wrote:
> On Tue, 20 Mar 2007 13:14:35 -0600
> cpw@....com (Cliff Wickman) wrote:
>
> > This patch reconciles cpusets and sched_domains that get out of sync
> > due to disabling and re-enabling of cpu's.
>
> I get three-out-of-three rejects in cpuset.c. I could fix them, but I
> wouldn't be very confident that the result works at runtime. 2.6.20-rc6 was
> a long time ago - please, always raise patches against the latest mainline
> kernel (the daily git snapshot suffices).
Will do.
> Recursion is a big no-no in kernel. Is there any way in which it can be
> avoided? Is Dinakar's implementation also recursive?
I was a little reluctant to use recursion, but this use parallels another,
existing such use in cpuset.c The depth of the recursion is only the depth of
the cpuset hierarchy, which is set up by an administrator, and which is
logically limited by the number of cpus in the system. e.g. it would be
hard to even deliberately organize 16 cpus into a hierarchy greater
than 16 layers deep, even if you wanted cpusets of single cpus.
We've not run into such a problem on systems of hundreds of cpus.
I would think it's safe. What do you think?
Dinakar's solution is not written yet, as far as I know. I'll copy him
for his status.
--
Cliff Wickman
Silicon Graphics, Inc.
cpw@....com
(651) 683-3824
-
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