[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20080307085703.123fe896.pj@sgi.com>
Date: Fri, 7 Mar 2008 08:57:03 -0600
From: Paul Jackson <pj@....com>
To: "Paul Menage" <menage@...gle.com>
Cc: a.p.zijlstra@...llo.nl, maxk@...lcomm.com, mingo@...e.hu,
tglx@...utronix.de, oleg@...sign.ru, rostedt@...dmis.org,
linux-kernel@...r.kernel.org, rientjes@...gle.com
Subject: Re: [RFC/PATCH] cpuset: cpuset irq affinities
Paul M wrote:
> An alternative would be to just have some kind of "irqsets" file in
> the top-level cpuset directory and let the user write irq group
> definitions into that file.
Yes, exactly, that's the alternative.
I tried that, in my mind, and got stuck on the complicated syntax that
would have been needed to represent an arbitrary length array of named
lists of irqs with each list having a priority attribute.
So I went with the separate "irqs.N.name" files, (ab)using the file
system directory apparatus to handle the "arbitrary length array of
named" entities aspect, burying the priority attribute (N) in the name,
and leaving each individual irqs.N.name file only needing to hold a
single vector of irq numbers.
A security conscious sysadmin can even assign different permissions to
the different irq lists with this. And updates of one irq list don't
endanger the other irq lists, thanks to the innate and elaborate
capabilities in the kernel vfs code to handle concurrent updates to
separate files correctly and reliably.
This reminds me of the difference between the Windows Registry (one big
awful file) and the Unix /etc directory (2745 files, on the system
nearest to my shell prompt.) Well, in this irq case, the different is not
-that- dramatic, but it is a small echo of such.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@....com> 1.940.382.4214
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists