How to assign process to work on partial CPU's?

Question

We want to run our applications ( process ) only on the first 6 CPUs. We have a RHEL machine.

We have physical DELL machine with total 12 cores (from lscpu)

Is it possible to assign the process to use only the first 6 cores?

Or other approach that mask the last 6 cores , so we can actually use only the first 6 cores , or decommission the last 6 cores ,

NOTE: the real reason for that is because we are pay licence per CORE and if we can use half of the total cores , then we can pay only half of the price

I can’t write an answer right now (anyone else can of course), you should use cgroups for this, there’s even a RHEL 7 resource management guide on the topic. — Stephen Kitt, Feb 23 '21 at 13:46
Related: How can I set the processor affinity of a process on Linux?, How to limit a process to one CPU core in Linux?, How to ensure exclusive CPU availability for a running process?, taskset(1) — ilkkachu, Feb 23 '21 at 14:12
@Stephen Kitt , what you wrote is very very interesting , is it mean for example that we can use only half of CPU? , this is exactly what we want , and I will explain , we are pay per CORE license , and our target is to use half of the total cores in order to pay half price , please let me know if we can achieve that? — yael, Feb 23 '21 at 15:37
dose GRUB_CMDLINE_LINUX="isolcpus=6" can be the solution for my question? ( from https://unix.stackexchange.com/questions/326579/how-to-ensure-exclusive-cpu-availability-for-a-running-process ) — yael, Feb 23 '21 at 16:09

telcoM · Accepted Answer · 2021-02-24T09:36:30.530

5

The term for this is CPU affinity. You can use the taskset command to set it for individual processes.

To run <command> on the first 6 cores (cores #0-#5) only:

taskset -c 0-5 <command> [arguments for command]

If the process is already running, you can set its affinity by PID instead:

taskset -c 0-5 -p <PID of an existing process>

If you want a restriction that will apply to the specific process and all its child processes, then you'll need cgroups as mentioned by Stephen Kitt in the comments. If the process in question is running as a systemd service, then you can just add CPUAffinity=0-5 to the [Service] section of the appropriate .service file (or create an override file).

But if you need to limit the number of cores used for licensing purposes, you'll need to find out which methods are accepted by the software vendor in question. They are likely to require a method that is not quite so easy to undo, or they might require a mechanism for e.g. daily reporting of how many cores (maximum) were used for this software each day.

edited Feb 24 '21 at 09:36

answered Feb 23 '21 at 14:45

telcoM

96,466

Damn, we really need some GUI for that on Linux. – X.LINK Feb 23 '21 at 15:40
Note that taskset only covers cpu affinity, and for RHEL and related systems, RedHat has issued advisories that numactl is preferred. For non-RHEL systems, taskset is sometimes the best that you can use. – Edwin Buck Feb 24 '21 at 16:16
@EdwinBuck The OP edited their question to clarify that the restriction is for licensing reasons - and that probably makes "best effort" -style soft restriction not an appropriate solution: a hard limit is very likely needed. But unless the OP actually discloses which vendor's software they're trying to apply the restriction to, only the vendor of that software can tell for sure what the actual restriction requirements are. – telcoM Feb 24 '21 at 16:29
@telcoM So it is more about making the system appear to have a different number of CPUs, instead of making the software only run on specific ones. Thanks for the note, I'm not sure if I answered before such clarification, or if I just missed that detail. In any case, I appreciate the comment to make it clear. – Edwin Buck Feb 24 '21 at 16:35

score 2 · Answer 2 · edited Feb 24 '21 at 09:17

Yes, on RedHat systems, typically a person uses numactl

While it cannot guarantee a process binds to a specific CPU (as it will permit binding to another CPU should the desired CPU be unavailable, it will configure the job launch to make the best effort to bind and (if the process sleeps) rebind to the desired CPUs.

Note that in this case, CPU means "thing that can run a program" and not a physical item. This means that (for this conversation) a real core is one CPU, it's hyperthread is another, and often there are many CPUs in a physical package. To get a listing of these CPUs:

cat /proc/cpuinfo

numactl --hardware shows the hardware layout. Each node is a "memory boundary" meaning that it is an isolated bit of RAM that is accessible from some CPUs more quickly than from other CPUs. The reason is typically because it's directly accessible by a set of CPUs, and other CPUs must make requests across these boundaries to access that bit of RAM. This is important because you can also direct numactl to use only certain memory boundaries. It is a good idea to specify a memory boundary that is local to the CPU, if you are specifying specific CPUs.
numactl --physcpubind=0-7 <command> will launch whatever you would normally run with <command> on cores 0 through 7.
numactl --physcpubind=0,7 <command> will launch <command> on either core 0 or 7.

Of course, both of these can "core miss" which is when the OS decides the core won't be available and launches the program on a non-specified core rather than delay the launch. The numactl option --localalloc will attempt to use memory local to the core, while --membind=... permits more explicit memory location binding.

numastat shows the numa_hits and numa_misses in statistic form for numactl launched processes. To see if any specific process hit or missed, you need to read the details from the /proc filesystem before the process terminates.

score 0 · Answer 3 · answered Feb 24 '21 at 16:41

Odds are that if you are trying to avoid he licensing cost, restricting which CPUs the software runs on isn't going to impact the software's core detection. You can request that the software only run on some cores, but the software will detect all the cores and check that number against the license / permitted configuration.

To make this work the way you want, I would recommend installing a HyperVisor, placing two operating systems on the same hardware platform. Some HyperVisors, like XEN can strongly partition hardware, while others can't. You will likely have more success with one that can strongly partition hardware (the hardware is configured to exclusive support a single VM) than other hypervisor solutions.

This comes with a few requirements. The CPUs will have to be roughtly spread out in two or more packages (actual CPU chips) for strong partitioning of CPUs to work, and the rest of the machine won't be able to access the portion reserved for this application. It's not 100% ideal due to these restrictions, but it is better than having to buy a new machine if you can live with these restrictions.

Good luck. It is often not 100% possible to know if this kind of solution works for your application until after you attempt it.

How to assign process to work on partial CPU's?

3 Answers3