Dinakar wrote:
> I'll ack this for now until I fix the problems that I am seeing
> on ppc64
Thanks, Dinakar.
Linus - do *NOT* actually apply the literal patch that Dinakar ack'd.
1) It's logic is backwards - arrgh.
2) It doesn't undo the other attempt to partially disable this.
3) It's not a
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
>
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
Dinakar wrote:
I'll ack this for now until I fix the problems that I am seeing
on ppc64
Thanks, Dinakar.
Linus - do *NOT* actually apply the literal patch that Dinakar ack'd.
1) It's logic is backwards - arrgh.
2) It doesn't undo the other attempt to partially disable this.
3) It's not a
Nick wrote:
> and that it looks like what I was thinking about.
Ok - I almost have my crosstool installation healthy again.
I will actually see to it that my patch builds this time for
whatever arch's I can test on, and send this simple disabling
of sched domain mangling from cpuset-land as a
Paul Jackson wrote:
So long as the cpuset code stops making any calls to partition_sched_domains()
whatsoever, then we should be back where we were in 2.6.12, so far as the
scheduler is concerned - right?
That's right - sorry I just meant disabling the dynamic sched
domains behaviour of the
Nick wrote:
> I get the feeling that exclusive cpusets should just be
> completely disabled for 2.6.13
No no - not disable exclusive cpusets - disable using them to try
to define sched domains.
That is, I hope you mean that Dinakar's patch that uses cpu_exclusive
cpusets to define sched domains
Paul Jackson wrote:
Dinakar wrote:
Can we hold on to this patch for a while, as I reported yesterday,
Sure - though I guess it's Linus or Andrew who will have to do
the holding.
I sent it off contingent on the approval of yourself, Hawkes and Nick.
I get the feeling that the problem
From: "Dinakar Guniguntala" <[EMAIL PROTECTED]>
Can we hold on to this patch for a while, as I reported yesterday,
this hangs up my ppc64 box on doing rmdir on a exclusive cpuset.
Still debugging the problem, hope to have a fix soon, Thanks
Paul's patch simply constrains the scope of cpuset
Dinakar wrote:
> Can we hold on to this patch for a while, as I reported yesterday,
Sure - though I guess it's Linus or Andrew who will have to do
the holding.
I sent it off contingent on the approval of yourself, Hawkes and Nick.
It looks like Linus is living dangerously and put it in already
Paul,
Can we hold on to this patch for a while, as I reported yesterday,
this hangs up my ppc64 box on doing rmdir on a exclusive cpuset.
Still debugging the problem, hope to have a fix soon, Thanks
-Dinakar
On Wed, Aug 24, 2005 at 04:15:10AM -0700, Paul Jackson wrote:
> As reported by
As reported by Paul Mackerras <[EMAIL PROTECTED]>, the previous
patch "cpu_exclusive sched domains fix" broke the ppc64 build,
yielding error messages:
kernel/cpuset.c: In function 'update_cpu_domains':
kernel/cpuset.c:648: error: invalid lvalue in unary '&'
kernel/cpuset.c:648: error: invalid
As reported by Paul Mackerras [EMAIL PROTECTED], the previous
patch cpu_exclusive sched domains fix broke the ppc64 build,
yielding error messages:
kernel/cpuset.c: In function 'update_cpu_domains':
kernel/cpuset.c:648: error: invalid lvalue in unary ''
kernel/cpuset.c:648: error: invalid lvalue
Paul,
Can we hold on to this patch for a while, as I reported yesterday,
this hangs up my ppc64 box on doing rmdir on a exclusive cpuset.
Still debugging the problem, hope to have a fix soon, Thanks
-Dinakar
On Wed, Aug 24, 2005 at 04:15:10AM -0700, Paul Jackson wrote:
As reported by
Dinakar wrote:
Can we hold on to this patch for a while, as I reported yesterday,
Sure - though I guess it's Linus or Andrew who will have to do
the holding.
I sent it off contingent on the approval of yourself, Hawkes and Nick.
It looks like Linus is living dangerously and put it in already
From: Dinakar Guniguntala [EMAIL PROTECTED]
Can we hold on to this patch for a while, as I reported yesterday,
this hangs up my ppc64 box on doing rmdir on a exclusive cpuset.
Still debugging the problem, hope to have a fix soon, Thanks
Paul's patch simply constrains the scope of cpuset
Paul Jackson wrote:
Dinakar wrote:
Can we hold on to this patch for a while, as I reported yesterday,
Sure - though I guess it's Linus or Andrew who will have to do
the holding.
I sent it off contingent on the approval of yourself, Hawkes and Nick.
I get the feeling that the problem
Nick wrote:
I get the feeling that exclusive cpusets should just be
completely disabled for 2.6.13
No no - not disable exclusive cpusets - disable using them to try
to define sched domains.
That is, I hope you mean that Dinakar's patch that uses cpu_exclusive
cpusets to define sched domains
Paul Jackson wrote:
So long as the cpuset code stops making any calls to partition_sched_domains()
whatsoever, then we should be back where we were in 2.6.12, so far as the
scheduler is concerned - right?
That's right - sorry I just meant disabling the dynamic sched
domains behaviour of the
Nick wrote:
and that it looks like what I was thinking about.
Ok - I almost have my crosstool installation healthy again.
I will actually see to it that my patch builds this time for
whatever arch's I can test on, and send this simple disabling
of sched domain mangling from cpuset-land as a real
20 matches
Mail list logo
