> > the numa case of "I prefer that cpu" is handled. Not the "I cannot work on
> > those".
>
> How is the NUMA case of I prefer that cpu handled?
it's exported via /sys/bus/pci/devices//local_cpus
(and the irq is in the /irq directory next to local_cpus)
-
To unsubscribe from this list: send
Arjan van de Ven <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>>> 1) is very real today
>>> 2) is partially real on some of the bigger numa stuff already.
>>
>> You have said you the NUMA cases is handled in another way already?
>
> the numa case of "I prefer that cpu" is handled. Not
Eric W. Biederman wrote:
1) is very real today
2) is partially real on some of the bigger numa stuff already.
You have said you the NUMA cases is handled in another way already?
the numa case of "I prefer that cpu" is handled. Not the "I cannot
work on those".
-
To unsubscribe from this
Arjan van de Ven <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>> What is the problem you are trying to solve?
>
> 2 problems
> 1) irq's that irqbalance should not touch at all
This is easy we just need a single bit. Not 128+ bytes on the huge
machines.
> 2) irqs that can only go to a
Eric W. Biederman wrote:
What is the problem you are trying to solve?
2 problems
1) irq's that irqbalance should not touch at all
2) irqs that can only go to a subset of processors.
1) is very real today
2) is partially real on some of the bigger numa stuff already.
-
To unsubscribe from this
Eric W. Biederman wrote:
What is the problem you are trying to solve?
2 problems
1) irq's that irqbalance should not touch at all
2) irqs that can only go to a subset of processors.
1) is very real today
2) is partially real on some of the bigger numa stuff already.
-
To unsubscribe from this
Arjan van de Ven [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
What is the problem you are trying to solve?
2 problems
1) irq's that irqbalance should not touch at all
This is easy we just need a single bit. Not 128+ bytes on the huge
machines.
2) irqs that can only go to a subset
Eric W. Biederman wrote:
1) is very real today
2) is partially real on some of the bigger numa stuff already.
You have said you the NUMA cases is handled in another way already?
the numa case of I prefer that cpu is handled. Not the I cannot
work on those.
-
To unsubscribe from this list:
Arjan van de Ven [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
1) is very real today
2) is partially real on some of the bigger numa stuff already.
You have said you the NUMA cases is handled in another way already?
the numa case of I prefer that cpu is handled. Not the I cannot work
the numa case of I prefer that cpu is handled. Not the I cannot work on
those.
How is the NUMA case of I prefer that cpu handled?
it's exported via /sys/bus/pci/devices/device/local_cpus
(and the irq is in the /irq directory next to local_cpus)
-
To unsubscribe from this list: send the
On 12/13/06, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
Arjan van de Ven <[EMAIL PROTECTED]> writes:
> the numa case is already handled; the needed info for that is exposed already
> enough... at least for irqbalance
What is the problem you are trying to solve?
If it is just interrupts
Arjan van de Ven <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>
>> There is still a question of how to handle the NUMA case but...
>>
>
> the numa case is already handled; the needed info for that is exposed already
> enough... at least for irqbalance
What is the problem you are trying
Eric W. Biederman wrote:
There is still a question of how to handle the NUMA case but...
the numa case is already handled; the needed info for that is exposed
already enough... at least for irqbalance
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
Arjan van de Ven <[EMAIL PROTECTED]> writes:
>> .
>>
>> In addition the cases I can think of allowed_affinity is the wrong
>> name. suggested_affinity sounds like what you are trying to implement
>> and when it is merely a suggestion and not a hard limit it doesn't
>> make sense to export like
* Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> > also there might be hardware that can only route a given IRQ to a
> > subset of CPUs. While setting set_affinity allows the
> > irqbalance-daemon to 'probe' this mask, it's a far from optimal API.
>
> I agree, I am just arguing that adding
Ingo Molnar <[EMAIL PROTECTED]> writes:
> * Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>
>> In addition the cases I can think of allowed_affinity is the wrong
>> name. suggested_affinity sounds like what you are trying to implement
>> and when it is merely a suggestion and not a hard limit
> .
>
> In addition the cases I can think of allowed_affinity is the wrong
> name. suggested_affinity sounds like what you are trying to implement
> and when it is merely a suggestion and not a hard limit it doesn't
> make sense to export like this.
it really IS a hard limit.
-
To unsubscribe
* Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> In addition the cases I can think of allowed_affinity is the wrong
> name. suggested_affinity sounds like what you are trying to implement
> and when it is merely a suggestion and not a hard limit it doesn't
> make sense to export like this.
Arjan van de Ven <[EMAIL PROTECTED]> writes:
> [due to a broken libata in current -git I've not been able to test this patch
> enough]
>
>
> This patch adds an "allowed_affinity" mask to each interrupt, in addition to
> the
> existing actual affinity mask. In addition this new mask is exported
[due to a broken libata in current -git I've not been able to test this patch
enough]
This patch adds an "allowed_affinity" mask to each interrupt, in addition to
the
existing actual affinity mask. In addition this new mask is exported to
userspace
in a similar way as the actual affinity is
[due to a broken libata in current -git I've not been able to test this patch
enough]
This patch adds an allowed_affinity mask to each interrupt, in addition to
the
existing actual affinity mask. In addition this new mask is exported to
userspace
in a similar way as the actual affinity is
Arjan van de Ven [EMAIL PROTECTED] writes:
[due to a broken libata in current -git I've not been able to test this patch
enough]
This patch adds an allowed_affinity mask to each interrupt, in addition to
the
existing actual affinity mask. In addition this new mask is exported to
* Eric W. Biederman [EMAIL PROTECTED] wrote:
In addition the cases I can think of allowed_affinity is the wrong
name. suggested_affinity sounds like what you are trying to implement
and when it is merely a suggestion and not a hard limit it doesn't
make sense to export like this.
well,
Ingo Molnar [EMAIL PROTECTED] writes:
* Eric W. Biederman [EMAIL PROTECTED] wrote:
In addition the cases I can think of allowed_affinity is the wrong
name. suggested_affinity sounds like what you are trying to implement
and when it is merely a suggestion and not a hard limit it doesn't
.
In addition the cases I can think of allowed_affinity is the wrong
name. suggested_affinity sounds like what you are trying to implement
and when it is merely a suggestion and not a hard limit it doesn't
make sense to export like this.
it really IS a hard limit.
-
To unsubscribe from
* Eric W. Biederman [EMAIL PROTECTED] wrote:
also there might be hardware that can only route a given IRQ to a
subset of CPUs. While setting set_affinity allows the
irqbalance-daemon to 'probe' this mask, it's a far from optimal API.
I agree, I am just arguing that adding another
Arjan van de Ven [EMAIL PROTECTED] writes:
.
In addition the cases I can think of allowed_affinity is the wrong
name. suggested_affinity sounds like what you are trying to implement
and when it is merely a suggestion and not a hard limit it doesn't
make sense to export like this.
it
Eric W. Biederman wrote:
There is still a question of how to handle the NUMA case but...
the numa case is already handled; the needed info for that is exposed
already enough... at least for irqbalance
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
Arjan van de Ven [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
There is still a question of how to handle the NUMA case but...
the numa case is already handled; the needed info for that is exposed already
enough... at least for irqbalance
What is the problem you are trying to solve?
On 12/13/06, Eric W. Biederman [EMAIL PROTECTED] wrote:
Arjan van de Ven [EMAIL PROTECTED] writes:
the numa case is already handled; the needed info for that is exposed already
enough... at least for irqbalance
What is the problem you are trying to solve?
If it is just interrupts irqbalanced
30 matches
Mail list logo
