From 88972d7d8133a4eb8cea065648469b1d30369d15 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?R=C3=A9mi=20Oudin?= Date: Tue, 30 Jan 2018 16:27:54 +0100 Subject: [PATCH] Better formatting of CPU usage documentation This is now displayed as a list, with bold fonts for each bullet. Refers https://github.com/borgbackup/borg/issues/3554 --- docs/usage_general.rst.inc | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/docs/usage_general.rst.inc b/docs/usage_general.rst.inc index 2a32c60c6..38d05cc0b 100644 --- a/docs/usage_general.rst.inc +++ b/docs/usage_general.rst.inc @@ -306,12 +306,12 @@ all the resource usage occurs in that one process, so just add up client + server to get the approximate resource usage. CPU client: - borg create: does chunking, hashing, compression, crypto (high CPU usage) - chunks cache sync: quite heavy on CPU, doing lots of hashtable operations. - borg extract: crypto, decompression (medium to high CPU usage) - borg check: similar to extract, but depends on options given. - borg prune / borg delete archive: low to medium CPU usage - borg delete repo: done on the server + - **borg create:** does chunking, hashing, compression, crypto (high CPU usage) + - **chunks cache sync:** quite heavy on CPU, doing lots of hashtable operations. + - **borg extract:** crypto, decompression (medium to high CPU usage) + - **borg check:** similar to extract, but depends on options given. + - **borg prune / borg delete archive:** low to medium CPU usage + - **borg delete repo:** done on the server It won't go beyond 100% of 1 core as the code is currently single-threaded. Especially higher zlib and lzma compression levels use significant amounts of CPU cycles. Crypto might be cheap on the CPU (if hardware accelerated) or