16

We have a computer whose CPU has 32 cores and it's going to be used for running programs by a few different users. Is there any way to restrict the number of cores each user can use at any time so that one user will not monopolize all the CPU power?

  • 5
    Not an answer, only an idea. You might want to look into setting up several virtual machines. Each could have only a limited amount of CPU-s. Each user would only be on one of the virtual machines, and the users on that VM would be limited in CPU usage. It might be that some of the virtualization softwares has tools for supporting this. – ghellquist Jan 9 at 17:16
  • 1
    @ghellquist you should make that an answer – slebetman Jan 10 at 0:38
  • @ghellquist: You probably want something as light-weight as possible, like Linux containers, if you just want different users to only see some of the CPUs. (e.g. so when they start an OpenMP or other program that starts as many threads as it sees cores, it will start an appropriate number for the amount of cores you're letting each user actually use). Full virtualization, like KVM, has a performance cost even with hardware support like VT-X or AMD-V, from extra levels of page tables even when VM exits are avoided, in code that gets any TLB misses from touching lots of memory. – Peter Cordes Jan 10 at 4:55
  • I'm sorry, but is there even a need for this? As a multi-user system, Linux by default already implements preemptive multitasking, so the situation where a single (non-malicious) user just hogs the entire system for themselves shouldn't come up. – Cubic Jan 10 at 15:37
15

While this is possible, it is complicated and almost certainly a bad idea. If only one user is using the machine at the moment, restricting them to N cores is a waste of resources. A far better approach would be to run everything with nice:

NAME
       nice - run a program with modified scheduling priority

SYNOPSIS
       nice [OPTION] [COMMAND [ARG]...]

DESCRIPTION
       Run  COMMAND  with an adjusted niceness, which affects process scheduling.  With
       no COMMAND, print the current niceness.  Niceness values range  from  -20  (most
       favorable to the process) to 19 (least favorable to the process).

This is a great tool that sets the priority of a process. So if only one user is running something, they'll get as much CPU time as they need, but if someone else launches their own (also niced) job, they will be nice and share with each other. That way, if your users all launch commands with nice 10 command, nobody will be hogging resources (and nobody will bring the server to its knees).

Note that a high nice value means a low priority. This is a measure of how nice we should be and the nicer we are, the more we share.

Also note that this will not help manage memory allocation, it only affectes CPU scheduling. So if multiple users launch multiple memory-intensive processes, you will still have a problem. If that's an issue, you should look into proper queuing systems such as torque.

  • Thanks for your answer. There are some "workload managers" such as SLURM but they are for computers with multiple nodes. I guess it makes sense that people have not developed similar apps for single node computers as there is not as much demand. – Reza Jan 9 at 15:54
  • @Reza try nice, from what you describe, that's pretty much exactly what you need. – terdon Jan 9 at 16:00
  • 3
    @Reza: That's because the OS already does that. It automatically time-shares the available CPUs to threads/processes as needed. – BlueRaja - Danny Pflughoeft Jan 9 at 19:19
12

TL;DR: From brief research it appears it is possible to restrict commands to specific number of cores, however in all cases you have to use a command which actually enforces the restriction.

cgroups

Linux has cgroups which is frequently used exactly for the purpose of restricting resources available to processes. From a very brief research, you can find an example in Arch Wiki with Matlab ( a scientific software ) configuration set in /etc/cgconfig.conf:

group matlab {
    perm {
        admin {
            uid = username;
        }
        task {
            uid = username;
        }
    }

    cpuset {
        cpuset.mems="0";
        cpuset.cpus="0-5";
    }
    memory {
        memory.limit_in_bytes = 5000000000;
    }
}

In order for such config to take effect, you have to run the process via cgexec command, e.g. from the same wiki page:

$ cgexec -g memory,cpuset:matlab /opt/MATLAB/2012b/bin/matlab -desktop

taskset

A related question on Ask Ubuntu and How to limit a process to one CPU core in Linux? [duplicate] on Unix&Linux site show an example of using taskset to limit the CPUs for the process. In the first question, it's achieved through parsing all processes for a particular user

$ ps aux | awk '/^housezet/{print $2}' | xargs -l taskset -p 0x00000001

In the the other question, a process is started via taskset itself:

$ taskset -c 0 mycommand --option  # start a command with the given affinity

Conclusion

While it is certainly possible to limit processes, it seems it's not so simple to achieve that for particular users. The example in linked Ask Ubuntu post would require consistent scanning for processes belonging to each user and using taskset on each new one. A far more reasonable approach would be to selectively run CPU intensive applications, either via cgexec or taskset; it also makes no sense to restrict all processes to specific number of CPUS, especially for those that actually make use of parallelism and concurrency to run their tasks faster - limiting them to specific number of CPUs can have the effect of slowing down the processing. Additionally, as terdon's answer mentioned it's a waste of resources

Running select applications via taskset or cgexec requires communicating with your users to let them know what applications they can run, or creating wrapper scripts which will launch select applications via tasksel or cgexec.

Additionally, consider setting number of processes a user or group can spawn instead of setting limit on number of CPUs. This can be achieved via /etc/security/limits.conf file.

See also

  • 1
    well, there is cgrulesengd and cgrules.conf to automatically move processes to the appropriate cgroup based on user/group instead of relying on the users running their processes with cgexec. But it seems, setting this up in ubuntu is somewhat non-trivial. – Hans-Jakob Jan 9 at 15:57
  • @Hans-Jakob It does look somewhat convoluted, plus requires adding kernel flags in GRUB. Probably for enterprise level of machine, where you do have lots of users and don't want them to crash the system, that's probably worthwhile, but for desktop - too much work. Thank you for linking that. – Sergiy Kolodyazhnyy Jan 9 at 16:02
  • 2
    sched_setaffinity(2) says the affinity mask is preserved across execve(2), and that a child inherits it on fork(2). So if you taskset the shell for a user (or their graphical shell for an X session), everything they start from that shell will, by default, use the same affinity mask. – Peter Cordes Jan 10 at 4:50
  • 1
    One possible downside is programs that check how many CPUs the machine has when deciding how many threads to start; they'll have too many threads for the number of cores they'll actually get scheduled on. Did you find out if cgroups might do anything about that? – Peter Cordes Jan 10 at 4:51
  • @PeterCordes Spawning shell idea sounds interesting. I'll need to look into that. Thanks ! As for second comment, no, I've not researched cgroups enough at this point. – Sergiy Kolodyazhnyy Jan 10 at 5:09

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.