> > 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 th
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 th
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 lis
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
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 irqbal
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 a
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 t
* 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 ano
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
> .
>
> 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.
w
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
[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 e
15 matches
Mail list logo
