Updates from editor

Author: Celiazhou1

support/azure/azure-kubernetes/create-upgrade-delete/aks-increased-memory-usage-cgroup-v2.md

@@ -23,38 +23,38 @@ You experience one or more of the following symptoms:
 
 ## Cause
 
-This increase is caused by a change in memory accounting within version 2 of the Linux control group (cgroup) API. [Cgroup v2](https://kubernetes.io/docs/concepts/architecture/cgroups/) is now the default cgroup version for Kubernetes 1.25 on AKS.
+This increase is caused by a change in memory accounting within version 2 of the Linux control group (`cgroup`) API. [Cgroup v2](https://kubernetes.io/docs/concepts/architecture/cgroups/) is now the default cgroup version for Kubernetes 1.25 on AKS.
 
 > [!NOTE]  
-> This issue is distinct from the memory saturation in nodes that's caused by applications or frameworks that aren't aware of cgroup v2. For more information, see [Memory saturation occurs in pods after cluster upgrade to Kubernetes 1.25](./aks-memory-saturation-after-upgrade.md).
+> This issue is distinct from the memory saturation in nodes that's caused by applications or frameworks that aren't aware of `cgroup` v2. For more information, see [Memory saturation occurs in pods after cluster upgrade to Kubernetes 1.25](./aks-memory-saturation-after-upgrade.md).
 
 ## Solution
 
 - If you observe frequent memory pressure on the nodes, upgrade your subscription to increase the amount of memory that's available to your virtual machines (VMs).
 
 - If you see a higher eviction rate on the pods, [use higher limits and requests for pods](/azure/aks/developer-best-practices-resource-management#define-pod-resource-requests-and-limits).
 
-- cgroup v2 uses a different API than cgroup v1. If there are any applications that directly access the cgroup file system, update them to later versions that support cgroup v2. For example:
+- `cgroup` v2 uses a different API than `cgroup` v1. If there are any applications that directly access the `cgroup` file system, update them to later versions that support `cgroup` v2. For example:
 
   - **Third-party monitoring and security agents**:
 
-     Some monitoring and security agents depend on the cgroup file system. Update these agents to versions that support cgroup v2.
+     Some monitoring and security agents depend on the `cgroup` file system. Update these agents to versions that support `cgroup` v2.
 
   - **Java applications**:
 
-     Use versions that fully support cgroup v2:
+     Use versions that fully support `cgroup` v2:
     - OpenJDK/HotSpot: `jdk8u372`, `11.0.16`, `15`, and later versions.
     - IBM Semeru Runtimes: `8.0.382.0`, `11.0.20.0`, `17.0.8.0`, and later versions.
     - IBM Java: `8.0.8.6` and later versions.
 
   - **uber-go/automaxprocs**:  
-    If you are using the `uber-go/automaxprocs` package, ensure the version is `v1.5.1` or later.
+    If you're using the `uber-go/automaxprocs` package, ensure the version is `v1.5.1` or later.
 
-- An alternative temporary solution is to revert the cgroup version on your nodes by using the DaemonSet. For more information, see [Revert to cgroup v1 DaemonSet](https://github.com/Azure/AKS/blob/master/examples/cgroups/revert-cgroup-v1.yaml).
+- An alternative temporary solution is to revert the `cgroup` version on your nodes by using the DaemonSet. For more information, see [Revert to cgroup v1 DaemonSet](https://github.com/Azure/AKS/blob/master/examples/cgroups/revert-cgroup-v1.yaml).
 
 > [!IMPORTANT]
 > - Use the DaemonSet cautiously. Test it in a lower environment before applying to production to ensure compatibility and prevent disruptions.
-> - By default, the DaemonSet applies to all nodes in the cluster and reboots them to implement the cgroup change.  
+> - By default, the DaemonSet applies to all nodes in the cluster and reboots them to implement the `cgroup` change.  
 > - To control how the DaemonSet is applied, configure a `nodeSelector` to target specific nodes.