From b90ba21fd225fc61dd40dfb4aa80dc1d0174bd99 Mon Sep 17 00:00:00 2001 From: Jan Vcelak Date: Wed, 18 Aug 2010 12:37:25 +0200 Subject: [PATCH] throughput-performance: s390x sysctl settings bz #619377 kernel: Process scheduler tuning recommendation for s390 --- .../throughput-performance/sysctl.s390x.ktune | 40 +++++++++++++++++++ 1 file changed, 40 insertions(+) create mode 100644 tune-profiles/throughput-performance/sysctl.s390x.ktune diff --git a/tune-profiles/throughput-performance/sysctl.s390x.ktune b/tune-profiles/throughput-performance/sysctl.s390x.ktune new file mode 100644 index 0000000..e584681 --- /dev/null +++ b/tune-profiles/throughput-performance/sysctl.s390x.ktune @@ -0,0 +1,40 @@ +# ktune sysctl settings for rhel6 servers, maximizing i/o throughput +# +# Minimal preemption granularity for CPU-bound tasks: +# (default: 1 msec# (1 + ilog(ncpus)), units: nanoseconds) +kernel.sched_min_granularity_ns = 10000000 + +# SCHED_OTHER wake-up granularity. +# (default: 1 msec# (1 + ilog(ncpus)), units: nanoseconds) +# +# This option delays the preemption effects of decoupled workloads +# and reduces their over-scheduling. Synchronous workloads will still +# have immediate wakeup/sleep latencies. +kernel.sched_wakeup_granularity_ns = 15000000 + +# TODO: this bits need comment +kernel.sched_latency_ns = 80000000 +kernel.sched_features = 15834234 +kernel.sched_tunable_scaling = 0 + +# If a workload mostly uses anonymous memory and it hits this limit, the entire +# working set is buffered for I/O, and any more write buffering would require +# swapping, so it's time to throttle writes until I/O can catch up. Workloads +# that mostly use file mappings may be able to use even higher values. +# +# The generator of dirty data starts writeback at this percentage (system default +# is 20%) +vm.dirty_ratio = 40 + +# Start background writeback (via writeback threads) at this percentage (system +# default is 10%) +#vm.dirty_background_ratio = 15 + +# PID allocation wrap value. When the kernel's next PID value +# reaches this value, it wraps back to a minimum PID value. +# PIDs of value pid_max or larger are not allocated. +# +# A suggested value for pid_max is 1024 * <# of cpu cores/threads in system> +# e.g., a box with 32 cpus, the default of 32768 is reasonable, for 64 cpus, +# 65536, for 4096 cpus, 4194304 (which is the upper limit possible). +#kernel.pid_max = 65536