Boot Parameter: maxcpus
by /dev/dog from LinuxQuestions.org on (#5AHGG)
LinuxWeeklyNews Article: A realtime developer's checklist
The article summarizes some things that concern realtime developers that non-realtime devs may not be aware of. At one point, the article mentions that a boot parameter maxcpus can be used to limit which cpus the kernel is aware of. It gave an example that a possible use case is bare metal applications running on them.
My question is: How does that affect memory usage and other system resources? I thought the kernel is meant to manage applications sharing system resources. How does a bare-metal application use any system resources without cooperating with the kernel?
A possibility that comes to mind is that certain resources are also inaccessible to the kernel, and the kernel treats the connection between those resources and the bare-metal app as a peripheral. I am not sure, hopefully someone can explain some other use cases and how a system manages resource sharing and communication.
Below is a relevant snippet from the article, since the article is still in subscriber-only mode.
Quote:
The article summarizes some things that concern realtime developers that non-realtime devs may not be aware of. At one point, the article mentions that a boot parameter maxcpus can be used to limit which cpus the kernel is aware of. It gave an example that a possible use case is bare metal applications running on them.
My question is: How does that affect memory usage and other system resources? I thought the kernel is meant to manage applications sharing system resources. How does a bare-metal application use any system resources without cooperating with the kernel?
A possibility that comes to mind is that certain resources are also inaccessible to the kernel, and the kernel treats the connection between those resources and the bare-metal app as a peripheral. I am not sure, hopefully someone can explain some other use cases and how a system manages resource sharing and communication.
Below is a relevant snippet from the article, since the article is still in subscriber-only mode.
Quote:
| CPU affinity is another important element in a realtime system. It might be critical to isolate code onto some CPUs. Ogness gave an example of an eight-CPU system divided into six CPUs for non-realtime applications and two for realtime. In Linux, CPU affinity is defined for each task and takes the form of a bitmask with one bit set for each allowed CPU. In addition to user-space tasks, interrupts and kernel threads can also have their affinity set. This is important, as they may interfere with realtime code. Ogness noted that the internal architecture of a processor will influence the realtime configuration. If two CPUs are sharing L2 caches, then they should be both realtime, as cache sharing between realtime and non-realtime applications may have an effect on realtime latency. The tool to set and query affinities is taskset, which can either start a task or modify an existing one. taskset also applies to threads. If run without a new mask, it will show what the current mask is. As with priorities, an associated system call exists: sched_setaffinity(). Ogness noted that it requires that _GNU_SOURCE be defined, since the sched_setaffinity() wrapper is a GNU C library (glibc) extension and not part of the POSIX API. It is also possible to influence CPU affinity in a deeper way using the maxcpus and isolcpus boot parameters. maxcpus limits the number of CPUs the kernel can see. If set to four in an eight-CPU system, it means that the kernel will see only four processors and the other four CPUs can be used differently, such as by a bare-metal realtime application. On the other hand, isolcpus indicates to the kernel that it should not put kernel threads on the indicated processors. When using isolcpus, Linux is aware of all of the CPUs and can use the isolated CPUs when threads are explicitly set to run on them. |