Путеводитель по Руководству Linux

  User  |  Syst  |  Libr  |  Device  |  Files  |  Other  |  Admin  |  Head  |



   cpuset    ( 7 )

ограничить процессы подмножествами процессоров и узлов памяти (confine processes to processor and memory node subsets)

  Name  |  Description  |  Files  |  Extended capabilities  |  Format  |  Rules  |    Permissions    |  Warning  |  Exceptions  |  Error  |  Versions  |  Note  |  Bugs  |  Examples  |  See also  |

Разрешения (Permissions)

The permissions of a cpuset are determined by the permissions of the directories and pseudo-files in the cpuset filesystem, normally mounted at /dev/cpuset.

For instance, a process can put itself in some other cpuset (than its current one) if it can write the tasks file for that cpuset. This requires execute permission on the encompassing directories and write permission on the tasks file.

An additional constraint is applied to requests to place some other process in a cpuset. One process may not attach another to a cpuset unless it would have permission to send that process a signal (see kill(2)).

A process may create a child cpuset if it can access and write the parent cpuset directory. It can modify the CPUs or memory nodes in a cpuset if it can access that cpuset's directory (execute permissions on the each of the parent directories) and write the corresponding cpus or mems file.

There is one minor difference between the manner in which these permissions are evaluated and the manner in which normal filesystem operation permissions are evaluated. The kernel interprets relative pathnames starting at a process's current working directory. Even if one is operating on a cpuset file, relative pathnames are interpreted relative to the process's current working directory, not relative to the process's current cpuset. The only ways that cpuset paths relative to a process's current cpuset can be used are if either the process's current working directory is its cpuset (it first did a cd or chdir(2) to its cpuset directory beneath /dev/cpuset, which is a bit unusual) or if some user code converts the relative cpuset path to a full filesystem path.

In theory, this means that user code should specify cpusets using absolute pathnames, which requires knowing the mount point of the cpuset filesystem (usually, but not necessarily, /dev/cpuset). In practice, all user level code that this author is aware of simply assumes that if the cpuset filesystem is mounted, then it is mounted at /dev/cpuset. Furthermore, it is common practice for carefully written user code to verify the presence of the pseudo-file /dev/cpuset/tasks in order to verify that the cpuset pseudo-filesystem is currently mounted.