[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <47D87BE5.4010702@qualcomm.com>
Date: Wed, 12 Mar 2008 17:57:09 -0700
From: Max Krasnyanskiy <maxk@...lcomm.com>
To: Paul Jackson <pj@....com>
CC: menage@...gle.com, mingo@...e.hu, a.p.zijlstra@...llo.nl,
linux-kernel@...r.kernel.org
Subject: Re: boot cgroup questions
Paul Jackson wrote:
> Max K wrote:
>> btw I still do not see the "incompatibility" argument.
>
> It's similar, perhaps, to what happens when we try to accomodate two
> architectures in one file system, with things like:
> /x86_64/bin
> /ia64/bin
> replacing the well known /bin.
>
> Things break. Apps such as the major batch schedulers (PBS and LSF)
> and various other tools and scripts buried here and there have come
> used to developing particular cpuset hierarchies over the last couple
> of years.
>
> Any time you force another dimension into such an existing hierarchy,
> things break, and people get annoyed.
>
> Sure ... the kernel doesn't care ... it can handle whatever hierarchy
> you like.
Crazy idea. How about we add support for sym links to the cgroup fs ?
It's still much cleaner imo than dealing with complex irq grouping schemes.
In other words with symlinks we could do
`-- cpuset
|-- A -> X/A
|-- B -> X/B
|-- C
`-- X
|-- A
`-- B
The software that is used to the flat structure won't know the difference.
Max
--
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