Arch linux zram generator

Arch Linux User Repository

Search Criteria

Package Details: zram-generator-git 0.3.2-1

Package Actions

Git Clone URL:	https://aur.archlinux.org/zram-generator-git.git (read-only, click to copy)
Package Base:	zram-generator-git
Description:	Systemd unit generator for zram devices
Upstream URL:	https://github.com/systemd/zram-generator
Licenses:	MIT
Conflicts:	zram-generator
Provides:	zram-generator
Submitter:	Prototik
Maintainer:	Prototik
Last Packager:	Prototik
Votes:	3
Popularity:	0.073418
First Submitted:	2020-06-06 20:48
Last Updated:	2021-03-25 16:22

Dependencies (4)

Required by (1)

Sources (3)

Latest Comments

egrupled commented on 2021-01-27 20:35

The build is broken because upstream changed master branch to main . Removing branch name from git address will fix this issue.

Also you need to modify build section as follows:

egrupled commented on 2020-06-16 09:08

@Prototik using half-memory is now upstream default[1] although they didn’t update example config. I think sending update for upstream example makes more sense than maintaining separate downstream example config in parallel.

Prototik commented on 2020-06-15 20:46

@egrupled upstream config installed as well into /usr/share/doc/zram-generator .

half-memory.conf.example just another example (inspired by Fedora’s SwapOnZRAM initiative) and I’ll try to keep it up-to-date with upstream changes.

egrupled commented on 2020-06-15 20:34

@Prototik I think using upstream example config is better than putting some custom example of yours here which may get out of sync.

Copyright © 2004-2021 aurweb Development Team.

AUR packages are user produced content. Any use of the provided files is at your own risk.

Источник

Использование zRam для увеличения количества доступной памяти под Linux

Уже 2 месяца использую на своих компьютерах модуль zRam и хочу поделиться результатами. На практике он позволил мне не используя раздел подкачки, и не получая видимого замедления работы компьютера увеличить размер оперативной памяти в 2.5-3 раза. На сервере виртуалок тот же подход позволил очень ощутимо увеличить отзывчивость при нехватке памяти.
Заинтересовавшихся прошу под кат.

zRam это экспериментальный модуль ядра Linux (ранее известный как «compcache»). Он увеличивает производительность путем предотвращения подкачки страниц на диск, используя сжатое блочное устройство в оперативной памяти, пока не появится необходимость использовать файл подкачки на жестком диске. Скорость обмена с оперативной памятью быстрее, чем с жестким диском, следовательно zRam позволяет Linux производить большее число операций подкачки, особенно на старых компьютерах с малым объемом оперативной памяти.

Для пользователя все выглядит так: для начала нужно загрузить модуль (предварительно скомпилировав если он отсутствует)

В num_devices задается количество сжатых блочных устройств, которое будет создано.
Для наиболее оптимального использования CPU стоит учесть: сжатие каждого устройства zram однопоточное. Потому я создаю их по количеству ядер.

При настройке модуля задается фиксированный размер НЕ сжатых данных в байтах

В итоге будет создано устройство /dev/zram0 заданного размера

Данные записанные на него будут прозрачно сжаты в памяти. Что делать с ним далее — уже ваш выбор, я на этих устройствах создаю разделы подкачки.

Далее уже ядро думает само какие данные туда складывать в зависимости от того как часто вы к ним обращаетесь и как много памяти свободно.

Мой опыт показывает, что степень сжатия обычно 1 к 3.

На практике это позволило на ноутбуке в 8Gb памяти вынести компиляцию libreoffice в tmpfs. (она требует 7 Гбайт временных файлов и примерно 1 Гбайт памяти потребляет каждый поток gcc при сборке).

Область применения такой идеи крайне широка:

• нетбуки: у девушки ноутбук в двух-ядерным Atom-мом. И всего лишь 2 гигабайта оперативной памяти (больше не вставить). В итоге одна «наглая рыжая морда» все время съедала всю память и посылала машину в swap. Подключил zRam и девушка довольна
• Сервера виртуализации: прозрачное сжатие памяти виртуальных машин может позволить выполнять большее число виртуальных машин одновременно: у нас есть сервер используемый для тестирования веб-приложения под различными конфигурациями клиентов (операционки, браузеры, версии плагинов к браузерам, настройки локалей и кодировок). Прохождение тестов на нем всегда было «задумчивым» процессом. Использование zRam позволило уменьшить время прохождение тестов с 30 минут до 18

Дополнение:
Изначально разработка велась под названием compcache, и первые рабочие версии были сделаны для ядра 2.6.26(Июль 2008)
Начиная с декабря 2009 года и ядра 2.6.33 оно доступно в ядре, в разделе Staging. Для более старый ядер патчи все еще доступны на вышеуказанном сайте.
В ядре 3.8 должно было быть вынесено из Staging, но это не произошло.

Источник

Arch linux zram generator

This page provides an introduction to swap space and paging on GNU/Linux. It covers creation and activation of swap partitions and swap files.

Linux divides its physical RAM (random access memory) into chunks of memory called pages. Swapping is the process whereby a page of memory is copied to the preconfigured space on the hard disk, called swap space, to free up that page of memory. The combined sizes of the physical memory and the swap space is the amount of virtual memory available.

Support for swap is provided by the Linux kernel and user-space utilities from the util-linux package.

Contents

Swap space

Swap space can take the form of a disk partition or a file. Users may create a swap space during installation or at any later time as desired. Swap space can be used for two purposes, to extend the virtual memory beyond the installed physical memory (RAM), and also for suspend-to-disk support.

If it is beneficial to extend the virtual memory with swap depends on the amount of installed physical memory. If the amount of physical memory is less than the amount of memory required to run all the desired programs, then it may be beneficial to enable swap. This avoids out of memory conditions, where the Linux kernel OOM killer mechanism will automatically attempt to free up memory by killing processes. To increase the amount of virtual memory to the required amount, add the necessary difference (or more) as swap space.

The biggest drawback of enabling swap is its lower performance, see section #Performance. Hence, enabling swap is a matter of personal preference: some prefer programs to be killed over enabling swap and others prefer enabling swap and slower system when the physical memory is exhausted.

To check swap status, use:

Or to show physical memory as well as swap usage:

Swap partition

The factual accuracy of this article or section is disputed.

A swap partition can be created with most GNU/Linux partitioning tools. Swap partitions are typically designated as type 82 . Even though it is possible to use any partition type as swap, it is recommended to use type 82 in most cases since systemd will automatically detect it and mount it (see below).

To set up a partition as Linux swap area, the mkswap(8) command is used. For example:

To enable the device for paging:

To enable this swap partition on boot, add an entry to /etc/fstab :

where the device_UUID is the UUID of the swap space.

See fstab for the file syntax.

Activation by systemd

systemd activates swap partitions based on two different mechanisms. Both are executables in /usr/lib/systemd/system-generators . The generators are run on start-up and create native systemd units for mounts. The first, systemd-fstab-generator , reads the fstab to generate units, including a unit for swap. The second, systemd-gpt-auto-generator inspects the root disk to generate units. It operates on GPT disks only, and can identify swap partitions by their type GUID, see systemd#GPT partition automounting for more information.

Disabling swap

To deactivate specific swap space:

Alternatively use the -a switch to deactivate all swap space.

Since swap is managed by systemd, it will be activated again on the next system startup. To disable the automatic activation of detected swap space permanently, run systemctl —type swap to find the responsible .swap unit and mask it.

Swap file

As an alternative to creating an entire partition, a swap file offers the ability to vary its size on-the-fly, and is more easily removed altogether. This may be especially desirable if disk space is at a premium (e.g. a modestly-sized SSD).

Manually

Swap file creation

Use dd to create a swap file the size of your choosing. For example, creating a 512 MiB swap file:

Set the right permissions (a world-readable swap file is a huge local vulnerability):

After creating the correctly sized file, format it to swap:

Activate the swap file:

Finally, edit the fstab configuration to add an entry for the swap file:

For additional information, see fstab#Usage.

Remove swap file

To remove a swap file, it must be turned off first and then can be removed:

Finally remove the relevant entry from /etc/fstab .

Automated

zram-generator

The aim of this tool is the creation of zram devices. It is written in Rust and resides in systemd’s GitHub. It can be installed with the zram-generator package. Configuration is straightforward and explained in the README.

systemd-swap

systemd-swap is a script for creating hybrid swap space from zram swaps, swap files and swap partitions. It is not affiliated with the systemd project.

Install the systemd-swap package. Uncomment and set swapfc_enabled=1 in the Swap File Chunked section of /etc/systemd/swap.conf . Start/enable the systemd-swap service.

Visit the authors GitHub page for more information and setting up the recommended configuration.

Swap encryption

Performance

Swap operations are usually significantly slower than directly accessing data in RAM. Disabling swap entirely to improve performance can sometimes lead to a degradation, since it decreases the memory available for VFS caches, causing more frequent and costly disk I/O.

Swap values can be adjusted to help performance:

Swappiness

The swappiness sysctl parameter represents the kernel’s preference (or avoidance) of swap space. Swappiness can have a value between 0 and 200 (max 100 if Linux /sys/fs/cgroup/memory/memory.swappiness or /proc/sys/vm/swappiness can be read in order to obtain the raw integer value.

To temporarily set the swappiness value:

To set the swappiness value permanently, create a sysctl.d(5) configuration file. For example:

To test and more on why this may work, take a look at this article.

VFS cache pressure

Another sysctl parameter that affects swap performance is vm.vfs_cache_pressure , which controls the tendency of the kernel to reclaim the memory which is used for caching of VFS caches, versus pagecache and swap. Increasing this value increases the rate at which VFS caches are reclaimed[1]. For more information, see the Linux kernel documentation.

Priority

If you have more than one swap file or swap partition you should consider assigning a priority value (0 to 32767) for each swap area. The system will use swap areas of higher priority before using swap areas of lower priority. For example, if you have a faster disk ( /dev/sda ) and a slower disk ( /dev/sdb ), assign a higher priority to the swap area located on the fastest device. Priorities can be assigned in fstab via the pri parameter:

Or via the —priority parameter of swapon:

If two or more areas have the same priority, and it is the highest priority available, pages are allocated on a round-robin basis between them.

Using zswap or zram

Zswap is a Linux kernel feature providing a compressed write-back cache for swapped pages. This increases the performance and decreases the IO-Operations. ZRAM creates a virtual compressed Swap-file in memory as alternative to a swapfile on disk.

Striping

There is no necessity to use RAID for swap performance reasons. The kernel itself can stripe swapping on several devices, if you just give them the same priority in the /etc/fstab file. Refer to The Software-RAID HOWTO for details.

Источник

Improving performance

This article provides information on basic system diagnostics relating to performance as well as steps that may be taken to reduce resource consumption or to otherwise optimize the system with the end-goal being either perceived or documented improvements to a system’s performance.

Contents

The basics

Know your system

The best way to tune a system is to target bottlenecks, or subsystems which limit overall speed. The system specifications can help identify them.

• If the computer becomes slow when large applications (such as LibreOffice and Firefox) run at the same time, check if the amount of RAM is sufficient. Use the following command, and check the «available» column:

• If boot time is slow, and applications take a long time to load at first launch (only), then the hard drive is likely to blame. The speed of a hard drive can be measured with the hdparm command:

• If CPU load is consistently high even with enough RAM available, then try to lower CPU usage by disabling running daemons and/or processes. This can be monitored in several ways, for example with htop , pstree or any other system monitoring tool:

• If applications using direct rendering are slow (i.e those which use the GPU, such as video players, games, or even a window manager), then improving GPU performance should help. The first step is to verify if direct rendering is actually enabled. This is indicated by the glxinfo command, part of the mesa-demos package:

• When running a desktop environment, disabling (unused) visual desktop effects may reduce GPU usage. Use a more lightweight environment or create a custom environment if the current does not meet the hardware and/or personal requirements.

Benchmarking

The effects of optimization are often difficult to judge. They can however be measured by benchmarking tools.

Storage devices

Multiple hardware paths

This article or section needs language, wiki syntax or style improvements. See Help:Style for reference.

An internal hardware path is how the storage device is connected to your motherboard. There are different ways to connect to the motherboard such as TCP/IP through a NIC, plugged in directly using PCIe/PCI, Firewire, Raid Card, USB, etc. By spreading your storage devices across these multiple connection points you maximize the capabilities of your motherboard, for example 6 hard-drives connected via USB would be much much slower than 3 over USB and 3 over Firewire. The reason is that each entry path into the motherboard is like a pipe, and there is a set limit to how much can go through that pipe at any one time. The good news is that the motherboard usually has several pipes.

1. Directly to the motherboard using PCI/PCIe/ATA
2. Using an external enclosure to house the disk over USB/Firewire
3. Turn the device into a network storage device by connecting over TCP/IP

Note also that if you have a 2 USB ports on the front of your machine, and 4 USB ports on the back, and you have 4 disks, it would probably be fastest to put 2 on front/2 on back than 3 on back/1 on front. This is because internally the front ports are likely a separate Root Hub than the back, meaning you can send twice as much data by using both than just 1. Use the following commands to determine the various paths on your machine.

Partitioning

Make sure that your partitions are properly aligned.

Multiple drives

If you have multiple disks available, you can set them up as a software RAID for serious speed improvements.

Creating swap on a separate disk can also help quite a bit, especially if your machine swaps frequently.

Layout on HDDs

This article or section is out of date.

If using a traditional spinning HDD, your partition layout can influence the system’s performance. Sectors at the beginning of the drive (closer to the outside of the disk) are faster than those at the end. Also, a smaller partition requires less movements from the drive’s head, and so speed up disk operations. Therefore, it is advised to create a small partition (10GB, more or less depending on your needs) only for your system, as near to the beginning of the drive as possible. Other data (pictures, videos) should be kept on a separate partition, and this is usually achieved by separating the home directory ( /home/user ) from the system ( / ).

Choosing and tuning your filesystem

Choosing the best filesystem for a specific system is very important because each has its own strengths. The File systems article provides a short summary of the most popular ones. You can also find relevant articles in Category:File systems.

Mount options

The noatime option is known to improve performance of the filesystem.

Other mount options are filesystem specific, therefore see the relevant articles for the filesystems:

Reiserfs

The data=writeback mount option improves speed, but may corrupt data during power loss. The notail mount option increases the space used by the filesystem by about 5%, but also improves overall speed. You can also reduce disk load by putting the journal and data on separate drives. This is done when creating the filesystem:

Replace /dev/sda1 with the partition reserved for the journal, and /dev/sdb1 with the partition for data. You can learn more about reiserfs with Funtoo Filesystem Guide.

Tuning kernel parameters

There are several key tunables affecting the performance of block devices, see sysctl#Virtual memory for more information.

Input/output schedulers

Background information

The input/output (I/O) scheduler is the kernel component that decides in which order the block I/O operations are submitted to storage devices. It is useful to remind here some specifications of two main drive types because the goal of the I/O scheduler is to optimize the way these are able to deal with read requests:

• An HDD has spinning disks and a head that moves physically to the required location. Therefore, random latency is quite high ranging between 3 and 12ms (whether it is a high end server drive or a laptop drive and bypassing the disk controller write buffer) while sequential access provides much higher throughput. The typical HDD throughput is about 200 I/O operations per second (IOPS).

• An SSD does not have moving parts, random access is as fast as sequential one, typically under 0.1ms, and it can handle multiple concurrent requests. The typical SSD throughput is greater than 10,000 IOPS, which is more than needed in common workload situations.

If there are many processes making I/O requests to different storage parts, thousands of IOPS can be generated while a typical HDD can handle only about 200 IOPS. There is a queue of requests that have to wait for access to the storage. This is where the I/O schedulers plays an optimization role.

The scheduling algorithms

One way to improve throughput is to linearize access: by ordering waiting requests by their logical address and grouping the closest ones. Historically this was the first Linux I/O scheduler called elevator.

One issue with the elevator algorithm is that it is not optimal for a process doing sequential access: reading a block of data, processing it for several microseconds then reading next block and so on. The elevator scheduler does not know that the process is about to read another block nearby and, thus, moves to another request by another process at some other location. The anticipatory I/O scheduler overcomes the problem: it pauses for a few milliseconds in anticipation of another close-by read operation before dealing with another request.

While these schedulers try to improve total throughput, they might leave some unlucky requests waiting for a very long time. As an example, imagine the majority of processes make requests at the beginning of the storage space while an unlucky process makes a request at the other end of storage. This potentially infinite postponement of the process is called starvation. To improve fairness, the deadline algorithm was developed. It has a queue ordered by address, similar to the elevator, but if some request sits in this queue for too long then it moves to an «expired» queue ordered by expire time. The scheduler checks the expire queue first and processes requests from there and only then moves to the elevator queue. Note that this fairness has a negative impact on overall throughput.

The Completely Fair Queuing (CFQ) approaches the problem differently by allocating a timeslice and a number of allowed requests by queue depending on the priority of the process submitting them. It supports cgroup that allows to reserve some amount of I/O to a specific collection of processes. It is in particular useful for shared and cloud hosting: users who paid for some IOPS want to get their share whenever needed. Also, it idles at the end of synchronous I/O waiting for other nearby operations, taking over this feature from the anticipatory scheduler and bringing some enhancements. Both the anticipatory and the elevator schedulers were decommissioned from the Linux kernel replaced by the more advanced alternatives presented below.

The Budget Fair Queuing (BFQ) is based on CFQ code and brings some enhancements. It does not grant the disk to each process for a fixed time-slice but assigns a «budget» measured in number of sectors to the process and uses heuristics. It is a relatively complex scheduler, it may be more adapted to rotational drives and slow SSDs because its high per-operation overhead, especially if associated with a slow CPU, can slow down fast devices. The objective of BFQ on personal systems is that for interactive tasks, the storage device is virtually as responsive as if it was idle. In its default configuration it focuses on delivering the lowest latency rather than achieving the maximum throughput.

Kyber is a recent scheduler inspired by active queue management techniques used for network routing. The implementation is based on «tokens» that serve as a mechanism for limiting requests. A queuing token is required to allocate a request, this is used to prevent starvation of requests. A dispatch token is also needed and limits the operations of a certain priority on a given device. Finally, a target read latency is defined and the scheduler tunes itself to reach this latency goal. The implementation of the algorithm is relatively simple and it is deemed efficient for fast devices.

Kernel’s I/O schedulers

While some of the early algorithms have now been decommissioned, the official Linux kernel supports a number of I/O schedulers which can be split into two categories:

• The multi-queue schedulers are available by default with the kernel. The Multi-Queue Block I/O Queuing Mechanism (blk-mq) maps I/O queries to multiple queues, the tasks are distributed across threads and therefore CPU cores. Within this framework the following schedulers are available:
  • None, where no queuing algorithm is applied.
  • mq-deadline, the adaptation of the deadline scheduler (see below) to multi-threading.
  • Kyber
  • BFQ

• The single-queue schedulers are legacy schedulers:
  • NOOP is the simplest scheduler, it inserts all incoming I/O requests into a simple FIFO queue and implements request merging. In this algorithm, there is no re-ordering of the request based on the sector number. Therefore it can be used if the ordering is dealt with at another layer, at the device level for example, or if it does not matter, for SSDs for instance.
  • Deadline
  • CFQ

Changing I/O scheduler

To list the available schedulers for a device and the active scheduler (in brackets):

To list the available schedulers for all devices:

To change the active I/O scheduler to bfq for device sda, use:

The process to change I/O scheduler, depending on whether the disk is rotating or not can be automated and persist across reboots. For example the udev rule below sets the scheduler to none for NVMe, mq-deadline for SSD/eMMC, and bfq for rotational drives:

Tuning I/O scheduler

Each of the kernel’s I/O scheduler has its own tunables, such as the latency time, the expiry time or the FIFO parameters. They are helpful in adjusting the algorithm to a particular combination of device and workload. This is typically to achieve a higher throughput or a lower latency for a given utilization. The tunables and their description can be found within the kernel documentation.

To list the available tunables for a device, in the example below sdb which is using deadline, use:

To improve deadline’s throughput at the cost of latency, one can increase fifo_batch with the command:

Power management configuration

When dealing with traditional rotational disks (HDD’s) you may want to lower or disable power saving features completely.

Reduce disk reads/writes

Avoiding unnecessary access to slow storage drives is good for performance and also increasing lifetime of the devices, although on modern hardware the difference in life expectancy is usually negligible.

Show disk writes

The iotop package can sort by disk writes, and show how much and how frequently programs are writing to the disk. See iotop(8) for details.

Relocate files to tmpfs

Relocate files, such as your browser profile, to a tmpfs file system, for improvements in application response as all the files are now stored in RAM:

• Refer to Profile-sync-daemon for syncing browser profiles. Certain browsers might need special attention, see e.g. Firefox on RAM.
• Refer to Anything-sync-daemon for syncing any specified folder.
• Refer to Makepkg#Improving compile times for improving compile times by building packages in tmpfs.

File systems

Refer to corresponding file system page in case there were performance improvements instructions, e.g. Ext4#Improving performance and XFS#Performance.

Swap space

Writeback interval and buffer size

Storage I/O scheduling with ionice

Many tasks such as backups do not rely on a short storage I/O delay or high storage I/O bandwidth to fulfil their task, they can be classified as background tasks. On the other hand quick I/O is necessary for good UI responsiveness on the desktop. Therefore it is beneficial to reduce the amount of storage bandwidth available to background tasks, whilst other tasks are in need of storage I/O. This can be achieved by making use of the linux I/O scheduler CFQ, which allows setting different priorities for processes.

The I/O priority of a background process can be reduced to the «Idle» level by starting it with

See ionice(1) and [2] for more information.

Overclocking

Overclocking improves the computational performance of the CPU by increasing its peak clock frequency. The ability to overclock depends on the combination of CPU model and motherboard model. It is most frequently done through the BIOS. Overclocking also has disadvantages and risks. It is neither recommended nor discouraged here.

Many Intel chips will not correctly report their clock frequency to acpi_cpufreq and most other utilities. This will result in excessive messages in dmesg, which can be avoided by unloading and blacklisting the kernel module acpi_cpufreq . To read their clock speed use i7z from the i7z package. To check for correct operation of an overclocked CPU, it is recommended to do stress testing.

Frequency scaling

Tweak default scheduler (CFS) for responsiveness

The default CPU scheduler in the mainline Linux kernel is CFS.

The upstream default settings are tweaked for high throughput which make the desktop applications unresponsive under heavy CPU loads. The following script sets the CFS to use same settings as the linux-zen kernel does.

The script can be made to run on startup using Systemd .

Alternative CPU schedulers

• MuQSS — Multiple Queue Skiplist Scheduler. Available with the -ck patch set developed by Con Kolivas.

https://wiki.archlinux.org/title/Unofficial_user_repositories/Repo-ck || linux-ck-uksmAUR

• PDS — Priority and Deadline based Skiplist multiple queue scheduler focused on desktop responsiveness.

https://cchalpha.blogspot.com/ || linux-pdsAUR

Real-time kernel

Some applications such as running a TV tuner card at full HD resolution (1080p) may benefit from using a realtime kernel.

Adjusting priorities of processes

Ananicy

Ananicy is a daemon, available as ananicy-git AUR or ananicy-cpp AUR , for auto adjusting the nice levels of executables. The nice level represents the priority of the executable when allocating CPU resources.

cgroups

Cpulimit

Cpulimit is a program to limit the CPU usage percentage of a specific process. After installing cpulimit , you may limit the CPU usage of a processes’ PID using a scale of 0 to 100 times the number of CPU cores that the computer has. For example, with eight CPU cores the percentage range will be 0 to 800. Usage:

irqbalance

The purpose of irqbalance is distribute hardware interrupts across processors on a multiprocessor system in order to increase performance. It can be controlled by the provided irqbalance.service .

Turn off CPU exploit mitigations

Turning off CPU exploit mitigations may improve performance. Use below kernel parameter to disable them all:

The explanations of all the switches it toggles are given at kernel.org. You can use spectre-meltdown-checker AUR for vulnerability check.

Graphics

Xorg configuration

Graphics performance may depend on the settings in xorg.conf(5) ; see the NVIDIA, ATI, AMDGPU and Intel articles. Improper settings may stop Xorg from working, so caution is advised.

Mesa configuration

The performance of the Mesa drivers can be configured via drirc. GUI configuration tools are available:

• adriconf (Advanced DRI Configurator) — GUI tool to configure Mesa drivers by setting options and writing them to the standard drirc file.

https://gitlab.freedesktop.org/mesa/adriconf/ || adriconf

• DRIconf — Configuration applet for the Direct Rendering Infrastructure. It allows customizing performance and visual quality settings of OpenGL drivers on a per-driver, per-screen and/or per-application level.

https://dri.freedesktop.org/wiki/DriConf/ || driconfAUR

Hardware video acceleration

Hardware video acceleration makes it possible for the video card to decode/encode video.

Overclocking

As with CPUs, overclocking can directly improve performance, but is generally recommended against. There are several packages in the AUR, such as amdoverdrivectrl AUR (old AMD/ATI cards), rocm-smi-lib64 AUR (recent AMD cards), nvclock AUR (old NVIDIA — up to Geforce 9), and nvidia-utils for recent NVIDIA cards.

Enabling PCI Resizable BAR

The PCI specification allows larger Base Address Registers to be used for exposing PCI devices memory to the PCI Controller. This can result in a performance increase for video cards. Having access to the the full vRAM improves performance, but also enables optimizations in the graphics driver. The combination of resizable BAR, above 4G encoding and these driver optimizations are what AMD calls AMD Smart Access Memory, currently available on AMD Series 500 chipset motherboards. This setting may not be available on all motherboards, and is known to sometimes cause boot problems on certain boards.

If the BAR has a 256M size, the feature is not enabled or not supported:

To enable it, enable the setting named «Above 4G Decode» or «>4GB MMIO» in your motherboard settings. Verify that the BAR is now larger:

RAM, swap and OOM handling

Clock frequency and timings

RAM can run at different clock frequencies and timings, which can be configured in the BIOS. Memory performance depends on both values. Selecting the highest preset presented by the BIOS usually improves the performance over the default setting. Note that increasing the frequency to values not supported by both motherboard and RAM vendor is overclocking, and similar risks and disadvantages apply, see #Overclocking.

Root on RAM overlay

If running off a slow writing medium (USB, spinning HDDs) and storage requirements are low, the root may be run on a RAM overlay ontop of read only root (on disk). This can vastly improve performance at the cost of a limited writable space to root. See liveroot AUR .

zram or zswap

The zram kernel module (previously called compcache) provides a compressed block device in RAM. If you use it as swap device, the RAM can hold much more information but uses more CPU. Still, it is much quicker than swapping to a hard drive. If a system often falls back to swap, this could improve responsiveness. Using zram is also a good way to reduce disk read/write cycles due to swap on SSDs.

Similar benefits (at similar costs) can be achieved using zswap rather than zram. The two are generally similar in intent although not operation: zswap operates as a compressed RAM cache and neither requires (nor permits) extensive userspace configuration.

Example: To set up one lz4 compressed zram device with 32GiB capacity and a higher-than-normal priority (only for the current session):

To disable it again, either reboot or run

A detailed explanation of all steps, options and potential problems is provided in the official documentation of the zram module.

The zram-generator package provides a systemd-zram-setup@.service unit to automatically initialize zram devices without users needing to enable/start the template or its instances. The following resources provide information on how to use it:

«The generator will be invoked by systemd early at boot», so usage is as simple as creating the appropriate configuration file(s) and rebooting. A sample configuration is provided in /usr/share/doc/zram-generator/zram-generator.conf.example. You can also check the swap status of your configured /dev/zramN devices by checking the unit status of the systemd-zram-setup@zramN.service instance(s).

The package zramswap AUR provides an automated script for setting up a swap with a higher priority and a default size of 20% of the RAM size of your system. To do this automatically on every boot, enable zramswap.service .

Alternatively, the zramd AUR package allows to setup zram automatically using zstd compression by default, its configuration can be changed at /etc/default/zramd . It can be started at boot by enabling the zramd.service unit.

Swap on zram using a udev rule

The example below describes how to set up swap on zram automatically at boot with a single udev rule. No extra package should be needed to make this work.

First, enable the module:

Configure the number of /dev/zram nodes you need.

Create the udev rule as shown in the example.

Add /dev/zram to your fstab.

Using the graphic card’s RAM

In the unlikely case that you have very little RAM and a surplus of video RAM, you can use the latter as swap. See Swap on video RAM.

Improving system responsiveness under low-memory conditions

On traditional GNU/Linux system, especially for graphical workstations, when allocated memory is overcommitted, the overall system’s responsiveness may degrade to a nearly unusable state before either triggering the in-kernel OOM-killer or a sufficient amount of memory got free (which is unlikely to happen quickly when the system is unresponsive, as you can hardly close any memory-hungry applications which may continue to allocate more memory). The behaviour also depends on specific setups and conditions, returning to a normal responsive state may take from a few seconds to more than half an hour, which could be a pain to wait in serious scenario like during a conference presentation.

While the behaviour of the kernel as well as the userspace things under low-memory conditions may improve in the future as discussed on kernel and Fedora mailing lists, users can use more feasible and effective options than hard-resetting the system or tuning the vm.overcommit_* sysctl parameters:

• Manually trigger the kernel OOM-killer with Magic SysRq key, namely Alt+SysRq+f .
• Use a userspace OOM daemon to tackle these automatically (or interactively).

Sometimes a user may prefer OOM daemon to SysRq because with kernel OOM-killer you cannot prioritize the process to (or not) terminate. To list some OOM daemons:

• systemd-oomd — Provided by systemd as systemd-oomd.service that uses cgroups-v2 and pressure stall information (PSI) to monitor and take action on processes before an OOM occurs in kernel space.

https://github.com/systemd/systemd, systemd-oomd(8) || systemd

• earlyoom — Simple userspace OOM-killer implementation written in C.

https://github.com/rfjakob/earlyoom || earlyoom

• oomd — OOM-killer implementation based on PSI, requires Linux kernel version 4.20+. Configuration is in JSON and is quite complex. Confirmed to work in Facebook’s production environment.

https://github.com/facebookincubator/oomd || oomdAUR

• nohang — Sophisticated OOM handler written in Python, with optional PSI support, more configurable than earlyoom.

https://github.com/hakavlad/nohang || nohang-gitAUR

• low-memory-monitor — GNOME developer’s effort that aims to provides better communication to userspace applications to indicate the low memory state, besides that it could be configured to trigger the kernel OOM-killer. Based on PSI, requires Linux 5.2+.

https://gitlab.freedesktop.org/hadess/low-memory-monitor/ || low-memory-monitor-gitAUR

Network

• Kernel networking: see Sysctl#Improving performance
• NIC: see Network configuration#Set device MTU and queue length
• DNS: consider using a caching DNS resolver, see Domain name resolution#DNS servers
• Samba: see Samba#Improve throughput

Watchdogs

A watchdog timer [. ] is an electronic timer that is used to detect and recover from computer malfunctions. During normal operation, the computer regularly resets the watchdog timer [. ]. If, [. ], the computer fails to reset the watchdog, the timer will elapse and generate a timeout signal [. ] used to initiate corrective [. ] actions [. ] typically include placing the computer system in a safe state and restoring normal system operation.

Many users need this feature due to their system’s mission-critical role (i.e. servers), or because of the lack of power reset (i.e. embedded devices). Thus, this feature is required for a good operation in some situations. On the other hand, normal users (i.e. desktop and laptop) do not need this feature and can disable it.

To disable watchdog timers (both software and hardware), append nowatchdog to your boot parameters.

To check the new configuration do:

After you disabled watchdogs, you can optionally avoid the loading of the module responsible of the hardware watchdog, too. Do it by blacklisting the related module, e.g. iTCO_wdt .

Either action will speed up your boot and shutdown, because one less module is loaded. Additionally disabling watchdog timers increases performance and lowers power consumption.

See [3], [4], [5], and [6] for more information.

Источник