lkml.org 
[lkml]   [2008]   [Mar]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC/PATCH] cpuset: cpuset irq affinities
Peter Zijlstra wrote:
> How about we make this in-kernel boot set, that by default contains all
> IRQs, all unbounded kthreads and all of user-space.
I assumed that this exactly what we meant by the boot set all along :).

One thing I wanted to clarify that by all IRQs we literally mean all of them
even those that do not have handlers yet. /proc/irqN/smp_affinity for example
is not available for the irqs are not active. In other words an IRQ must not
all of the sudden show up in the root set when something does request_irq() on
it.
This applies to other thing too.

>> How does all this interact with /proc/irq/N/smp_affinity?
>
> Much the same way the cpuset cpus_allowed interacts with a task's
> cpus_allowed. That is, cs->cpus_allowed is a mask on top of the provided
> affinity.
>
> If for some reason the cs->cpus_allowed changes in such a way that the
> user-specified mask becomes empty (irq->cpus_allowed & cs->cpus_allowed
> == 0), then print a message and set it to the full mask
> (irq->cpus_allowed = cs->cpus_allowed).
>
> If for some reason the cs->cpus_allowed changes in such a way that the
> mask is physically impossible (set_irq_affinity(cs->cpus_allowed)
> fails), then print a message and move the IRQ to the parent set.

I think Paul missed my earlier reply where I pointed out that original patch
conflicted with /proc/irq/N/smp_affinity API. The solution is for
irq_set_affinity() to enforce cpus_allowed just like sched_setaffinity does
for the tasks.

Max


\
 
 \ /
  Last update: 2008-03-05 20:21    [W:0.105 / U:0.364 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site