Messages in this thread | | | Date | Thu, 10 Apr 2008 10:24:26 -0700 | From | Max Krasnyanskiy <> | Subject | Re: boot cgroup questions |
| |
Sorry for disappearing on you guys. I'm working on releasing the user-space framework and engine that uses cpu isolation for hard-RT. Once that's done I'm going to resurrect these efforts. In the mean time let me reply to your last comments.
Paul Jackson wrote: >> How about we add support for sym links to the cgroup fs ? > > Still pollutes the primary cpuset name space ... you have all > the directories X, X/A, and X/B as well as the symlinks A and B. > > Symlinks allow for one path that needs to be 'aliased' to another, > but they are a one-way map; without an exhaustive search of the > potential namespace, one can't invert them, or determine if they > can't be inverted. > > Tools have to constantly make heuristic decisions whether to > default to dereferencing the symlink, or not, and often have to > provide alternatives for the non-default choice. > > They are a pain in the backside even if designed in and expected > up front. > > If added as critical structure after the fact, something breaks, > pretty much for sure. > > For one minor example, code I've probably buried someplace that > does "find /dev/cpuset -type d" to find all cpusets would break. > > Or the one-line /sbin/cpuset_release_agent script: > rmdir /dev/cpuset/$1 > is broken -- fails to clean-up associated symlinks, and can't > avoid race conditions if it tries to add code to do that. > >> Crazy idea. > > Agreed ;)
Got it. Symlinks are out :)
Max
| |