Received-SPF: pass (google.com: domain of linux-kernel+bounces-108809-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Message-ID: <be8cfada-f4bd-4894-848d-1b7706b14035@virtuozzo.com>
Date: Wed, 20 Mar 2024 18:55:05 +0800
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] mm/memcontrol: stop resize loop if limit was changed
 again
Content-Language: en-US
To: Michal Hocko <mhocko@suse.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>,
 Roman Gushchin <roman.gushchin@linux.dev>,
 Shakeel Butt <shakeel.butt@linux.dev>, Muchun Song <muchun.song@linux.dev>,
 Andrew Morton <akpm@linux-foundation.org>,
 Vladimir Davydov <vdavydov.dev@gmail.com>, cgroups@vger.kernel.org,
 linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel@openvz.org
References: <20240320100556.463266-1-ptikhomirov@virtuozzo.com>
 <Zfq6XaACmN2JssTW@tiehlicka>
From: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
In-Reply-To: <Zfq6XaACmN2JssTW@tiehlicka>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?MW16SWRlRmNYNmNQR1VyempsVmVPZ2lKdmdwdGJWdVV0OWpReXdxMlRQSXll?=
 =?utf-8?B?T1JMRWNiZDBwVTFiMnNzaFJGQ1pOVWNLdFo1eS9sK1JyTXN1aXNsMlZmeTBO?=
 =?utf-8?B?RzVvZ0JHWDllVDlDOWRHTmdja1lwWFFrbysvekpXM2NXN21ad0JXRlB5K3VH?=
 =?utf-8?B?VWZnTXN4VENIS1RieENpMjJHRHpWMEVJRnRoUTVDS0FmeE5qUUswc2FvVms3?=
 =?utf-8?B?ei8rOWIzRkI0MkNSTERFODh1cXlQeEpwamV5TTNmcE15N2hyb2tnTXc0cHg4?=
 =?utf-8?B?dXBKcENFUFZkQm9pUWIwalBUWmthN3ExN0tvdUsrMEpLNExVMDU2bHdTcTRs?=
 =?utf-8?B?Y2hzdVFJeklSYnc1Rm9LMndZZU9PNWdoTjQxVmVMQm1VL09ZdXFoTy9UOGg0?=
 =?utf-8?B?L0J1ZFduVDd6M1ZFQWF2OHhVbS9qamtLVnRxNDdZaVNPb2o3VXIya3RwZkY2?=
 =?utf-8?B?YVJIVE9CRW9EZGlaY3dCdzZaLzlYZjBvQ2dBVitQVHFKY25MdCt5QnNJMGdX?=
 =?utf-8?B?TzZEWFYzRUFDWkwrbnBjM0hEbGxlR3pJZUluUHdNU0xFeDZHdkJlYVBFdUg1?=
 =?utf-8?B?Tm91dUhNaFFFbGdyd2ZTY0dpSmpwTlRaQmp2MFBIVDBnQURCVEdZL1FFdWZp?=
 =?utf-8?B?QVl6YllMMDYrNHFMUndUTkRRME1iNzJocldNVlpxRXhwa2tBSytaV2p5d2xy?=
 =?utf-8?B?SFAvZ2dpVmhMbDllT0lxWkNJNHV2OUNtS3VoaTEwenNoKzFSMWFLemlXSlJB?=
 =?utf-8?B?Q1UyVUc1QStFdnlaYWRnWCtIeXNEN01SVmhBV3B0cGcyaVVqSEV4cGFTUmRa?=
 =?utf-8?B?cUE1S09Lb3R5Z0hCenVTWUdRdHhHancxV0orenRhYnFoUEFhWGxDU3VybFk4?=
 =?utf-8?B?VkQxNmRwazFVY3JVcE8xejdkaHdibnpDWUMvTlJHTE5QUjVRZzBQLzVZQUJG?=
 =?utf-8?B?TzZtem5iU2VJYVZFSUZDbXFMdzVrV0c4ZWZSNDhLYnExaktTQUZOUzUxeEFD?=
 =?utf-8?B?LzZ5MXpJbGkrVXNHRDZKK29NUUh4bXJuRktaaGx2bXdZMXhkK29QYStjYzVq?=
 =?utf-8?B?RmxENEpka1FMR09qbGI2YjcwV1podkdJcDhPck5rWnVJZ0RycUV6ckp6YXFZ?=
 =?utf-8?B?RHhHR2s1eG1FTlVDalpuOGF1Q1htYlVBcmMxc1RRa0FOZ2dJNitkQXY4cXgy?=
 =?utf-8?B?czJ6WFRyZHhtSlZWNFA2V0ovVC9pUFVYTW5rdVlPeXBNWGZqd0dTejN4YWZH?=
 =?utf-8?B?NzJ2RnZHWWhNKy9tYlIvZkVGcFR4OVFqZE0rTitDY0k5SDQzZkRZTUkxaEhy?=
 =?utf-8?B?UUhveGV6UGNaUUcvZEVFWExlYk1YeG1CUlFRVlFYTkUxRG5wTGJ6RVg0eXds?=
 =?utf-8?B?aE8xaEUvWkJkVUU4MGxGeDRoRzZLbHB1ZWpOQ0xxNEFzazdmQ3AyN2Erckt4?=
 =?utf-8?B?U1FjSDdtS2FDK1JxNElFdm5YQkc0bkl2VDNiUXBEK3ZPOUllZ3RtUzBiY24r?=
 =?utf-8?B?RmM0bTZFK09kNEU3TjRabHdYa3FyeUFtWUNaS1VWcjhHMGJnMUJxSGVwMld4?=
 =?utf-8?B?Y3Q5dzhnVW5pckVsWFdrQXUyUE1mMy9pbkRGKzhNTThKamo4dENZenR1US9R?=
 =?utf-8?B?bEdpUmJjU3NWbFFHb2xFeHJmd0lHSnZzdG81cTNrYUx4U1M0LzF3UXB2bkJO?=
 =?utf-8?B?ellFcHBVSEFpYnpKbnVZRDI5UjMwUW44UHZQLzJkR2hDNmZGZHNjQmlQOWlO?=
 =?utf-8?B?cFlXUEl0cnFjOWZQRzZiUzI5TkVGWVRKR3V3clNvaWhvTkJGV2lkakIvYU4y?=
 =?utf-8?B?a213TWhBVlFUbUpYeUlrb1BVaXFTZVQyT2pIYnRRMW5jaDVoR1BTTFhPd0Z4?=
 =?utf-8?B?dU02ZlJKTjNDZkVpZUJoYzIwdGlFOXptUE9pSkVLOVcxNzNjQmFBMmpsVkto?=
 =?utf-8?B?Wm1rRHM0eWdGRXZhS0RHbDJ1bjN2bTZCNG05ais0TmZOellOMjdoV0JDaW5I?=
 =?utf-8?B?dEd1TDZjSlNuQnR4aXBNQzFxZVRzR0ZlUytSbG9tVEpvc0FvT05IVEhFZENC?=
 =?utf-8?B?bUY2VU1ROFEvQXAweE5DSXF2dWxYRThZcEY5R3Q2TVIvN1lETDV5MHEzYTdq?=
 =?utf-8?B?ZkpLblBOdVd6OE15eUFTcXNUYTZZRjlsYlBoN25yUDBCQkwxQmEwZURlT2tr?=
 =?utf-8?B?eU9kb2RnbXd3ZVB1RlZwYjZCMlpaQTNiQVhOdHI0MU85ekhObkV3WTUvRG8w?=
 =?utf-8?B?MW1tN0lvUWlObmFQYlJ0RHhsSnpBPT0=?=
X-OriginatorOrg: virtuozzo.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 84a8df26-7ba0-41b7-cb45-08dc48cc381e
X-MS-Exchange-CrossTenant-AuthSource: DU0PR08MB9003.eurprd08.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Mar 2024 10:55:13.4604
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 0bc7f26d-0264-416e-a6fc-8352af79c58f
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: X2jDTyb6Kg68EY1LfgnFNhgHWuMmBeFR52AxAErQnENLIhm2VH407t9fyUgxX69/m7DEjyQlRkdyrEYwnVPICKXR1B2kL+B7zWVRH3pZjlA=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAXPR08MB7525


On 20/03/2024 18:28, Michal Hocko wrote:
> On Wed 20-03-24 18:03:30, Pavel Tikhomirov wrote:
>> In memory_max_write() we first set memcg->memory.max and only then
>> try to enforce it in loop. What if while we are in loop someone else
>> have changed memcg->memory.max but we are still trying to enforce
>> the old value? I believe this can lead to nasty consequence like getting
>> an oom on perfectly fine cgroup within it's limits or excess reclaim.
> 
> I would argue that uncoordinated hard limit configuration can cause
> problems on their own.

Sorry, didn't know that.

> Beside how is this any different from changing
> the high limit while we are inside the reclaim loop?

I believe reclaim loop rereads limits on each iteration, e.g. in 
reclaim_high(), so it should always be enforcing the right limit.

> 
>> We also have exactly the same thing in memory_high_write().
>>
>> So let's stop enforcing old limits if we already have a new ones.
> 
> I do see any reasons why this would be harmful I just do not see why
> this is a real thing or why the new behavior is any better for racing
> updaters as those are not deterministic anyway. If you have any actual
> usecase then more details would really help to justify this change.
> 
> The existing behavior makes some sense as it enforces the given limit
> deterministically.

I don't have any actual problem, usecase or reproduce at hand, I only 
see a potential problem:

Let's imagine that:

a) We set cgroup max limit to some small value, memory_max_write updates 
memcg->memory.max and starts spinning in loop as it wants to reclaim 
some memory which does not fit in new limit.

b) We don't need small limit anymore and we raise the limit to a big 
value, but memory_max_write() from (a) is still spinning. And if we are 
lucky enough and processes of cgroup are constantly consuming memory, to 
compensate effect from memory_max_write() from (a), so that it will 
continue spinning there forever.

Yes it is not that bad, because memory_max/high_write() also constantly 
checks for pending signals in loop so they won't actually get 
irreversibly stuck. But I just thought it was worth fixing.

> 
>> Signed-off-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
>> ---
>>   mm/memcontrol.c | 6 ++++++
>>   1 file changed, 6 insertions(+)
>>
>> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
>> index 61932c9215e7..81b303728491 100644
>> --- a/mm/memcontrol.c
>> +++ b/mm/memcontrol.c
>> @@ -6769,6 +6769,9 @@ static ssize_t memory_high_write(struct kernfs_open_file *of,
>>   		unsigned long nr_pages = page_counter_read(&memcg->memory);
>>   		unsigned long reclaimed;
>>   
>> +		if (memcg->memory.high != high)
>> +			break;
>> +
>>   		if (nr_pages <= high)
>>   			break;
>>   
>> @@ -6817,6 +6820,9 @@ static ssize_t memory_max_write(struct kernfs_open_file *of,
>>   	for (;;) {
>>   		unsigned long nr_pages = page_counter_read(&memcg->memory);
>>   
>> +		if (memcg->memory.max != max)
>> +			break;
>> +
>>   		if (nr_pages <= max)
>>   			break;
>>   
>> -- 
>> 2.43.0
> 

-- 
Best regards, Tikhomirov Pavel
Senior Software Developer, Virtuozzo.