OSDOCS-16871-1-abstracts: SCALE-1: Core Scalability Planning and Resource Management

Author: dfitzmau

modules/admin-quota-limits.adoc

@@ -7,7 +7,7 @@
 = Limit ranges in a LimitRange object 
 
 [role="_abstract"]
-To define compute resource constraints at the object level, create a `LimitRange` object. By creating this object, you can specify the exact amount of resources that an individual pod, container, image, or persistent volume claim can consume.
+To define compute resource constraints at the object level, create a `LimitRange` object. By creating this object, you can specify the exact amount of resources that an individual pod, container, image, image stream, or persistent volume claim can consume.
 
 All requests to create and modify resources are evaluated against each `LimitRange` object in the project. If the resource violates any of the enumerated constraints, the resource is rejected. If the resource does not set an explicit value, and if the constraint supports a default value, the default value is applied to the resource.
 

modules/admin-quota-usage.adoc

@@ -7,7 +7,7 @@
 = Admin quota usage
 
 [role="_abstract"]
-To ensure projects remain within defined constraints, monitor admin quota usage. By tracking the aggregate consumption of compute resources and storage, you can identify when `ResourceQuota` limits are reached or approached.
+To ensure projects remain within defined constraints, monitor admin quota usage. After a resource quota for a project is first created, the project restricts the ability to create any new resources that can violate a quota constraint until it has calculated updated usage statistics.
 
 Quota enforcement::
 +

modules/configure-guest-caching-for-disk.adoc

@@ -7,7 +7,7 @@
 = Configure guest caching for disk
 
 [role="_abstract"]
-To ensure that the guest manages caching instead of the host, configure your disk devices. This setting shifts caching responsibility to the guest operating system, preventing the host from caching disk operations.
+To ensure that the guest manages caching instead of the host, configure your disk devices.
 
 Ensure that the driver element of the disk device includes the `cache="none"` and `io="native"` parameters.
 

modules/configuring-quota-synchronization-period.adoc

@@ -7,7 +7,7 @@
 = Configuring quota synchronization period
 
 [role="_abstract"]
-To control the synchronization time frame when resources are deleted, configure the `resource-quota-sync-period` setting. This parameter in the `/etc/origin/master/master-config.yaml` file determines how frequently the system updates usage statistics to reflect deleted resources.
+When a set of resources are deleted, the synchronization time frame of resources is determined by the `resource-quota-sync-period` setting in the `/etc/origin/master/master-config.yaml` file. You can change the `resource-quota-sync-period` setting to have the set of resources regenerate in the needed amount of time (in seconds) for the resources to be once again available.
 
 [NOTE]
 ====

modules/create-perf-profile-workload-partitioning.adoc

@@ -7,7 +7,7 @@
 = Performance profiles and workload partitioning
 
 [role="_abstract"]
-To enable workload partitioning, apply a performance profile. This configuration specifies the isolated and reserved CPUs, ensuring that customer workloads run on dedicated cores without interruption from platform processes.
+To enable workload partitioning, apply a performance profile.
 
 An appropriately configured performance profile specifies the `isolated` and `reserved` CPUs. Create a performance profile by using the Performance Profile Creator (PPC) tool.
 

modules/disabling-the-cpuset-cgroup-controller.adoc

@@ -7,7 +7,7 @@
 = Disabling the cpuset cgroup controller
 
 [role="_abstract"]
-To allow the kernel scheduler to freely distribute processes across all available resources, disable the `cpuset` cgroup controller. This configuration prevents the system from enforcing processor affinity constraints, ensuring that tasks can use any available CPU or memory node.
+You can disable the cpuset cgroup controller. Disabling the controller requires a restart of the libvirtd daemon. 
 
 [NOTE]
 ====

modules/enabling-workload-partitioning.adoc

@@ -7,7 +7,7 @@
 = Enabling workload partitioning 
 
 [role="_abstract"]
-To partition cluster management pods into a specified CPU affinity, enable workload partitioning. This configuration ensures that management pods operate within the reserved CPU limits defined in your Performance Profile, preventing them from consuming resources intended for customer workloads.
+To partition cluster management pods into a specified CPU affinity, enable workload partitioning. This configuration ensures that management pods operate within the reserved CPU limits defined in your Performance Profile.
 
 Consider additional post-installation Operators that use workload partitioning when calculating how many reserved CPU cores to set aside for the platform.
 

modules/ibm-z-boost-networking-performance-with-rfs.adoc

@@ -7,7 +7,7 @@
 = Boosting networking performance with RFS
 
 [role="_abstract"]
-To boost networking performance, activate Receive Flow Steering (RFS) by using the Machine Config Operator (MCO). This configuration improves packet processing efficiency by directing network traffic to specific CPUs.
+To boost networking performance, activate Receive Flow Steering (RFS) by using the Machine Config Operator (MCO). This configuration improves packet processing efficiency.
 
 RFS extends Receive Packet Steering (RPS) by further reducing network latency. RFS is technically based on RPS, and improves the efficiency of packet processing by increasing the CPU cache hit rate. RFS achieves this, while considering queue length, by determining the most convenient CPU for computation so that cache hits are more likely to occur within the CPU. This means that the CPU cache is invalidated less and requires fewer cycles to rebuild the cache, which reduces packet processing run time.
 

modules/ibm-z-choose-networking-setup.adoc

@@ -7,7 +7,7 @@
 = Choose your networking setup
 
 [role="_abstract"]
-To optimize performance for specific workloads and traffic patterns, select a networking setup based on your chosen hypervisor. This configuration ensures the networking stack meets the operational requirements of {product-title} clusters on IBM Z infrastructure.
+For {ibm-z-name} setups, the networking setup depends on the hypervisor of your choice. Depending on the workload and the application, the best fit usually changes with the use case and the traffic pattern.
 
 The networking stack is one of the most important components for a Kubernetes-based product like {product-title}.
 

modules/ibm-z-rhel-kvm-host-recommendations.adoc

@@ -7,6 +7,8 @@
 = {op-system-base} KVM on {ibm-z-title} host recommendations
 
 [role="_abstract"]
-To optimize Kernel-based Virtual Machine (KVM) performance on {ibm-z-title}, apply host recommendations. Because optimal settings depend strongly on specific workloads and available resources, finding the best balance for your {op-system-base} environment often requires experimentation to avoid adverse effects.
+To optimize Kernel-based Virtual Machine (KVM) performance on {ibm-z-title}, apply host recommendations. 
+
+Optimizing a KVM virtual server environment strongly depends on the workloads of the virtual servers and on the available resources. The same action that enhances performance in one environment can have adverse effects in another. Finding the best balance for a particular setting can be a challenge and often involves experimentation.
 
 The following sections introduces some best practices when using {product-title} with {op-system-base} KVM on {ibm-z-name} and {ibm-linuxone-name} environments.