diff --git a/DC-SLES-kernel-control-groups b/DC-SLES-kernel-control-groups
new file mode 100644
index 000000000..0a083c74b
--- /dev/null
+++ b/DC-SLES-kernel-control-groups
@@ -0,0 +1,18 @@
+# This file originates from the project https://github.com/openSUSE/doc-kit
+# This file can be edited downstream.
+
+## Basics
+MAIN="kernel-control-groups.asm.xml"
+SRC_DIR="articles"
+IMG_SRC_DIR="images"
+
+## Profiling
+PROFOS="sles"
+PROFCONDITION="16.0"
+#PROFARCH="x86_64;zseries;power;aarch64"
+
+DOCBOOK5_RNG_URI="urn:x-suse:rng:v2:geekodoc-flat"
+
+## stylesheet location
+STYLEROOT="/usr/share/xml/docbook/stylesheet/suse2022-ns"
+FALLBACK_STYLEROOT="/usr/share/xml/docbook/stylesheet/suse2021-ns"
\ No newline at end of file
diff --git a/articles/kernel-control-groups.asm.xml b/articles/kernel-control-groups.asm.xml
new file mode 100644
index 000000000..4b633a202
--- /dev/null
+++ b/articles/kernel-control-groups.asm.xml
@@ -0,0 +1,145 @@
+
+
+
+%entities;
+]>
+
+
+
+
+
+
+
+
+
+
+
+
+
+Legal Notice
+
+
+GNU Free Documentation License
+
+
+
+
+Understanding Kernel Control Groups
+
+
+2026-09-04
+
+
+Initial version
+
+
+
+
+
+
+
+
+&x86-64;
+&power;
+&zseries;
+&aarch64;
+
+
+
+&productname;
+
+
+Understanding Kernel Control Groups
+
+How to use Kernel Control Groups.
+
+
+Kernel Control Groups
+
+
+Configuration
+Storage
+Maintenance
+Administration
+
+
+Products & Solutions
+
+
+
+https://bugzilla.suse.com/enter_bug.cgi
+Documentation
+SUSE Linux Enterprise Server 16.0
+SUSE Linux Enterprise Server 16.0
+shalaka.harne@suse.com
+
+yes
+
+
+
+
+WHAT?
+
+
+From granular resource allocation to real-time performance monitoring and isolation, control groups (cgroups) enable you to manage how system resources like CPU, memory, and network bandwidth are distributed among your processes in an organized way.
+
+
+
+
+WHY?
+
+
+This article provides a comprehensive overview of managing system resources and process isolation through the use of kernel control groups (cgroups).
+
+
+
+
+EFFORT
+
+
+The average reading time of this article is approximately 30 minutes.
+
+
+
+
+GOAL
+
+
+ You will be able to manage and isolate your system's hardware resources efficiently using kernel control groups (cgroups).
+
+
+
+
+REQUIREMENTS
+
+ System must be configured to use the modern unified hierarchy to access the full range of resource controllers and avoid legacy v1 limitations.
+Use use Btrfs, Ext4, or XFS to ensure the kernel can properly track and charge background I/O operations to the correct groups.
+Ensure that BFQ scheduler must be active on your block devices to enable the proportional weighting and prioritization of disk traffic.
+Ensure that you use systemd as your primary management interface to define resource limits through systemctl or dedicated unit files.
+For resource management within non-root user sessions, you must explicitly delegate controllers to the user's systemd instance via drop-in configuration files.
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/concepts/cgroups-about.xml b/concepts/cgroups-about.xml
new file mode 100644
index 000000000..fe5a3e1b5
--- /dev/null
+++ b/concepts/cgroups-about.xml
@@ -0,0 +1,96 @@
+
+
+ %entities;
+]>
+
+
+
+
+
+
+ About Kernel Control groups
+
+
+ Kernel control groups provide a hierarchical framework for organizing processes to strictly monitor, isolate, and limit their consumption of system resources like CPU, memory, and I/O.
+
+
+
+
+ Every process is assigned to exactly one administrative control group (cgroup). These cgroups are organized into a unified hierarchical tree structure, allowing you to manage resource allocation for individual processes or entire branches of the hierarchy simultaneously. You can define specific limitations for system resources, including CPU, Memory, Disk I/O, and Network Bandwidth.
+
+ On &productname;, &systemd; serves as the primary manager for cgroups, organizing all processes into logical units called slices. This integration provides a consistent interface for monitoring and setting resource properties across the OS.
+ To visualize your current system organization, use the systemd-cgls command to display the hierarchy tree.
+The Modern Unified Hierarchy (cgroup v2)
+ The Linux kernel previously supported two API variants (v1 and v2). &productnameshort; exclusively utilizes the unified (v2) hierarchy as the default and recommended mode.
+ Unified (v2)
+ A single hierarchy where all resource controllers are managed under a unified structure, providing better consistency and easier resource accounting.
+
+Hybrid/Legacy (v1)
+In this mode controllers are spread across multiple v1 hierarchies—is considered legacy in &productnameshort; .
+
+
+
+Legacy cgroup Support
+cgroup v1 is functionally obsolete in &productname;. Many modern system features and container runtimes now require the unified v2 hierarchy to operate correctly. Use of the legacy mode should be restricted to environments with strict requirements for aging, incompatible applications.
+To force the system into the legacy hybrid hierarchy, you must append systemd.unified_cgroup_hierarchy=0 as a kernel command-line parameter in the GRUB 2 boot loader. For detailed instructions on modifying boot parameters, refer to the &productnameshort; Administration Guide.
+
+Resource accounting
+Organizing processes into different cgroups can be used to obtain per-cgroup resource consumption data. Activating accounting for one unit also implicitly activates it for all units in the same slice and all parent slices.
+For per-unit setting, use directives like MemoryAccounting=.
+For global setting, edit /etc/systemd/system.conf with DefaultMemoryAccounting=.
+
+
+Setting resource limits
+Limitations to cgroups are primarily set with the systemctl set-property command.
+systemctl set-property [--runtime] NAME PROPERTY1=VALUE[PROPERTY2=VALUE]
+NAME: A &systemd; service, scope, or slice name.
+--runtime: Optional. Use this if you do not want values to persist after reboot.
+PROPERTY: Properties such as CPU, Memory, Tasks, I/O, and Network.
+
+
+
+ Preventing Fork Bombs with <literal>TasksMax</literal>
+
+ systemd supports configuring task count limits
+ to prevent runaway processes from crashing the system. While upstream
+ systemd sets strict limits (typically 15%
+ of the kernel global limit), &slea; defaults to infinity
+ to provide maximum flexibility for diverse workloads.
+
+
+
+ Overriding Defaults
+
+ To prevent system crashes from unintended process proliferation, you can
+ set a global default limit. For example, to set a limit of 256 tasks per
+ unit, create a drop-in configuration file at
+ /etc/systemd/system.conf.d/90-system-tasksmax.conf:
+
+[Manager]
+DefaultTasksMax=256
+
+ After creating the file, reload the systemd
+ manager configuration and verify the change:
+
+sudo systemctl daemon-reload
+systemctl show --property DefaultTasksMax
+DefaultTasksMax=256
+
+
+ Setting this value too low can cause services like databases or web
+ servers to fail with "Resource temporarily unavailable" errors. Always
+ calibrate the TasksMax value based on the specific
+ threading requirements of your application.
+
+
+
+
+