From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f47.google.com (mail-wr1-f47.google.com [209.85.221.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 22CA23921C7 for ; Wed, 18 Mar 2026 11:47:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.47 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773834426; cv=none; b=oOB4fT1VWaAPRkbCU4kAWE/nrN+2ekhHRvmLX5s6sROoHotPy9ANwyBBYXjOsUosXhbPSOpqqGcahHHASyj8d1zgtt3etx/790NJsL8an+04G8cAKIU+Km95PSx5RBtRoFdtprhr5HV6rgGDO9asBagGnIpGJotuz/sjAbTHeqU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773834426; c=relaxed/simple; bh=qGJkUU026cCsLttfeYYuW9q3aD0hKwRfxjLRXqzmExU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Ryx3zYSSwJLdMgt5D1bonOdQYYwdZSZFwONCeF2G8qG4pufuyF8KVodkeQ+0+681lrZD84in6XD4WznGXVefM7UI1NEtf97XpERX3Eo+IAVhg4ovZWkcXytI8eWuV3Uci5/xvIEOrX2iQ4RHNkEF2dBiTIrCexHHa/v7O/RK5/Y= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=aWXMmTzw; arc=none smtp.client-ip=209.85.221.47 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="aWXMmTzw" Received: by mail-wr1-f47.google.com with SMTP id ffacd0b85a97d-439c6fc2910so5148012f8f.0 for ; Wed, 18 Mar 2026 04:47:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773834423; x=1774439223; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=sXC+9ZKhTZVbYXK2Yzou2mwOrk2yBPN5TmkkaKwC8RI=; b=aWXMmTzwNGhZrdOGIIZYE3qeoGrRUIbqFLd6ivcFShk+6HgMV07icsxjpiaLM52Ie2 zYZM2En8l4O5I6ejCQoU+s9ly80RDacPO3Aj70u0bzX96OgXvrssP2jFeFE72DFQHwzb TAjLLnoGhllz2k3ZcHuIdIioPouhWo/pMXjHDhha3eXRqWl0THD01Jd0gQLk/GHICo5m SSPoAY1UGLXvT3jSKlVW6DMwG799BYtR8/h9AQjkKmSsS1yW/1EWGsR4JLtjEJFn+Vgv rdhCQEelTSVGntEfKHrRfrkHAl0+NWXdy7bmeBPuWDJD6nUdfxOYY+1zv3H9sUIrSxwF 4FxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773834423; x=1774439223; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=sXC+9ZKhTZVbYXK2Yzou2mwOrk2yBPN5TmkkaKwC8RI=; b=qDeBAKT7jIL0eZZmJEBmZVbjTs0ZYT/fIvUaX1QDWOxh+MQliUEtiLRk5bkrq9KGWn 7AxcwG8yfPI9PEbOXro7sXGJXU46/MBiSPPxo/DCv0AUrackqs2K3Y26hvLccD+F5bFo GnvqVkrOhhE4xjBHXXv75TqTOd4IqlmMlNeKycJq3DLHewDwlOra9O31JyfB4he7zRGp SVrg6pyiZ/ttxbLQhFoUcZs6WjGz+sfbn7/3Ep0HBgnYU/gw9XwBa15sBv4Kb+TeyLYA 94GUQEOLUmhvvszImqT4+RhOnV7KVXV++Wi7xH38U3frBmX9sydgF4aTaMIGGqTNjZ8z BLKA== X-Forwarded-Encrypted: i=1; AJvYcCWFF5ZttBvVizBUDWqWTtru0BHc11h1iLNu8CRh6cKl7swT4VRJOo960cwxhNQYUqvL/4piP0cwhxK2xzg=@vger.kernel.org X-Gm-Message-State: AOJu0YxDBaGWdGwg434n2i8WkWLZzdN8AK216aXs8P+RIr5mhNlYBY5J kfyFJb7LphhXEvNYKpb7cx04LjC3r8dVKBTi/rDuAhF/tx9E2qb6GvQ/L+rh5fTiZ14= X-Gm-Gg: ATEYQzy6dU++sJdAamm5u8UOY3u16xHmI1cPPA0/fRHJnJPrvL7tYsRI6jY1iJndkVH sPr1B+q0P6wirU6YWtkAKOY378xHzYO9YKdlEj8e7oQBqOdoCsOEwVEuGwSlJZ16YoQ8yn0qwTd LdiFD6d9aaesZoejQpPP/89gpsrXW2fPFS1ueoPdyM2L6DJspu+68DkjKJl6B7F1VGH8wl0O7P9 gk/m6Vva6+loT0vbYG1VIrkCZobRincn17Dx0p4aaBUBFN8bOSiyZqREPh/3KANuGn2jI/hv6ml 92p27miNm0MT/K4tFuPmem+l4Yts5afOu81cOSJF70beXgAW4w0LLVvRXpcAVxZO3eNKOh9VRTA NsFBczSCuzW2C4cD24TGWOnscYGkTQ3A+JmsAGIoe7CA1tGhJ8XjoStI3gk9h9Ym5ANy6xW/g6d /8aJvOBLnNimzKnceBgqLE1acioZxeNJGmXk0Q X-Received: by 2002:a05:6000:1ac6:b0:43b:4362:8ef5 with SMTP id ffacd0b85a97d-43b527cb2fdmr5198029f8f.51.1773834423360; Wed, 18 Mar 2026 04:47:03 -0700 (PDT) Received: from localhost (109-81-21-195.rct.o2.cz. [109.81.21.195]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43b518588a0sm11451811f8f.16.2026.03.18.04.47.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 Mar 2026 04:47:02 -0700 (PDT) Date: Wed, 18 Mar 2026 12:47:01 +0100 From: Michal Hocko To: Daniil Tatianin Cc: Andrew Morton , Johannes Weiner , Roman Gushchin , Shakeel Butt , Muchun Song , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Axel Rasmussen , Yuanchu Xie , Wei Xu , Brendan Jackman , Zi Yan , cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, yc-core@yandex-team.ru Subject: Re: [PATCH] mm: add memory.compact_unevictable_allowed cgroup attribute Message-ID: References: <20260317100058.2316997-1-d-tatianin@yandex-team.ru> <20260317121736.f73a828de2a989d1a07efea1@linux-foundation.org> <3db237d0-1ee8-44b7-a356-f3015173f7c2@yandex-team.ru> <7ca9876c-f3fa-441c-9a21-ae0ee5523318@yandex-team.ru> <73322279-c6f8-4319-827b-938c20c96b9b@yandex-team.ru> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Wed 18-03-26 13:08:31, Daniil Tatianin wrote: > > On 3/18/26 1:01 PM, Michal Hocko wrote: > > On Wed 18-03-26 12:25:17, Daniil Tatianin wrote: > > > On 3/18/26 12:20 PM, Michal Hocko wrote: > > [...] > > > > Shouldn't those use mlock? > > > Absolutely, mlock is required to mark a folio as unevictable. Note that > > > unevictable folios are still > > > perfectly eligible for compaction. This new property makes it so a cgroup > > > can say whether its > > > unevictable pages should be compacted (same as the global > > > compact_unevictable_allowed sysctl). > > If the mlock is already used then why do we need a per memcg control as > > well? Do we have different classes of mlocked pages some with acceptable > > compaction while others without? OK, I have misread the intention and this is exactly focused at mlock rather than general protection of all memcg charged memory. Now > The way it works is mlock(2) only prevents pages from being evicted > from the page cache by setting unevictable | mlocked flags on the > page. Such pages, however, are still allowed for compaction by > default, unless /proc/sys/vm/compact_unevictable_allowed is set to 0. > That property essentially "promotes" ALL such (unevictable) pages to a > new synthetic tier by making compaction skip them. The per-cgroup > property works similarly, however, it allows the scope to be much > smaller: from a global setting that promotes literally ALL unevictable > (mlocked) pages to this tier, to only promoting pages belonging to the > cgroup that has memory.compact_unevictable_allowed as 0. This is clear but what is not really clear to me is whether this is worth having as mlock workloads are already quite specific, the amount of mlocked memory shouldn't really consume huge portion of the memory so you still need to have a solid usecase where such a micro management really is worth it. In other words why a global compact_unevictable_allowed is not sufficient. -- Michal Hocko SUSE Labs