NUMA is bust with CONFIG_PREEMPT=y

NUMA is bust with CONFIG_PREEMPT=y

[Andrew Morton]

#define numa_node_id()  (__cpu_to_node(smp_processor_id()))

Either you're going to have to change that to get_cpu_only_on_numa() and
add the matching put_cpu_only_on_numa()'s, or disable preempt in
the config system.

Now, it's probably the case that this happens to work OK;
if you hop CPUs you just end up doing a suboptimal cross-node
operation.  But it'd be better to fix it up, IMO.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: NUMA is bust with CONFIG_PREEMPT=y

[Martin J. Bligh]

> Either you're going to have to change that to get_cpu_only_on_numa() and
> add the matching put_cpu_only_on_numa()'s, or disable preempt in
> the config system.

I'd favour the latter. It doesn't seem that useful on big machines like this, and
adds significant complication ... anyone really want it on a NUMA box? If not,
I'll make a patch to disable it for NUMA machines ...

M.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: NUMA is bust with CONFIG_PREEMPT=y

[Robert Love]

On Wed, 2002-10-02 at 17:49, Martin J. Bligh wrote:

> I'd favour the latter. It doesn't seem that useful on big machines like this,
> and adds significant complication ... anyone really want it on a NUMA box? If
> not, I'll make a patch to disable it for NUMA machines ...

I am not one of the 12 people in the world with a NUMA-Q, but I would
not like to see you disable kernel preemption.

I would really like to see it work on every architecture in every
configuration.  Is it that hard to make the requisite changes to fix it
up?

If nothing else, I think you guys can _infinitely_ benefit from the
atomicity checking infrastructure that is now in place.

Besides, why screw yourself over from the day when preemption is a
requirement? </semi-kidding> ;-)

just my two bits,

	Robert Love


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: NUMA is bust with CONFIG_PREEMPT=y

[Martin J. Bligh]

>> I'd favour the latter. It doesn't seem that useful on big machines like this,
>> and adds significant complication ... anyone really want it on a NUMA box? If
>> not, I'll make a patch to disable it for NUMA machines ...
> 
> I am not one of the 12 people in the world with a NUMA-Q, but I would
> not like to see you disable kernel preemption.

What does it buy you on a large NUMA box over the low-latency patches?

> Besides, why screw yourself over from the day when preemption is a
> requirement? </semi-kidding> ;-)

A scary thought ....

M.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: NUMA is bust with CONFIG_PREEMPT=y

[Robert Love]

On Wed, 2002-10-02 at 18:04, Martin J. Bligh wrote:

> > I am not one of the 12 people in the world with a NUMA-Q, but I would
> > not like to see you disable kernel preemption.
> 
> What does it buy you on a large NUMA box over the low-latency patches?

Latency-wise?  Probably very little.  But note Andrew is not going to
maintain the low-latency patches through 2.6/3.0 as far as I know.

The reasons I asked for you to keep it were mainly (a) so everything can
support it, and (b) for the useful atomicity/sleeping debugging checks.

And when I get consumer-level NUMA x86-64 in hopefully a few years I
need kernel preemption to work :)

	Robert Love

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/