Both kernels split the virtual address space into a user portion and a kernel portion. The kernel portion is shared between all processes in the system, and so the kernel is limited to that much directly addressable memory. Each user process in the system has its own user portion of the address space. Classically this split was done in the middle, giving each half 2gb. Windows can be directed to move the split to 3gb for user and 1gb for kernel with the /3gb boot.ini switch. The linux kernel is rather configurable at build time, and last I checked, the Ubuntu kernels build with the 3:1 split.
PAE allows for 64 gb of physical ram to be addressed, but any given page table still is limited to 4gb. Because there is only one kernel portion of that address space shared between all processes on the system, it is limited to 1 or 2 GB of directly addressable ram no matter what. Additional physical memory can be used, but it has to be only partially mapped into the virtual address space at any given time, and the mappings changed when needed. Because each process has a separate user address space, you can have, for example, 5 different processes that each have 2gb of their own memory that maps to different parts of 16gb of physical ram you have installed, and the kernel using another 2gb.
Note that the filesystem cache does not have to keep pages mapped all the time, so it can use plenty more of that physical ram, and the kernel automatically maps bits of it when needed, then unmaps it so it can map other pages. This trickery allows the kernel to use many gb of memory for the cache, and a few hundred mb for other uses, even when the kernel only has 1gb of virtual address space to play with.
Also worth noting is that in recent versions of Windows, Microsoft has instituted various artificial product licensing limitations. The Windows 7 Pro I am stuck with on my PC at work refuses to use physical ram addresses > 4gb even if I enable PAE, which results in it only being able to use 3.4 of the 4.0 gb of ram installed, since a chunk of the ram is relocated over the 4gb mark to leave room for things like the video ram to be located under 4gb.
Times change and so do best practices.
The current best way to do this is to run systemctl edit myservice
, which will create an override file for you or let you edit an existing one.
In normal installations this will create a directory /etc/systemd/system/myservice.service.d
, and inside that directory create a file whose name ends in .conf
(typically, override.conf
), and in this file you can add to or override any part of the unit shipped by the distribution.
For instance, in a file /etc/systemd/system/myservice.service.d/myenv.conf
:
[Service]
Environment="SECRET=pGNqduRFkB4K9C2vijOmUDa2kPtUhArN"
Environment="ANOTHER_SECRET=JP8YLOc2bsNlrGuD6LVTq7L36obpjzxd"
Also note that if the directory exists and is empty, your service will be disabled! If you don't intend to put something in the directory, ensure that it does not exist.
For reference, the old way was:
The recommended way to do this is to create a file /etc/sysconfig/myservice
which contains your variables, and then load them with EnvironmentFile
.
For complete details, see Fedora's documentation on how to write a systemd script.
Best Answer
The manpage for
systemd.exec
has a list of LimitXXXX instructions and a handy table comparing them to theulimit
options, by way of thesetrlimit()
system call.To limit the process's entire address space (
ulimit -v
) useLimitAS=
. Otherwise to limit the just the stack (ulimit -s
) useLimitSTACK=
or data segment (ulimit -d
) useLimitDATA=
According to the
setrlimit()
manpage, these limits will cause allocating additional memory to fail. STACK and AS will terminate the program with a sigsegv if the limit is reached and the stack needs to grow (and the program did not handle this).