From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933061AbeALJIN (ORCPT + 1 other); Fri, 12 Jan 2018 04:08:13 -0500 Received: from mail-eopbgr00090.outbound.protection.outlook.com ([40.107.0.90]:27199 "EHLO EUR02-AM5-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754442AbeALJIG (ORCPT ); Fri, 12 Jan 2018 04:08:06 -0500 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=aryabinin@virtuozzo.com; Subject: Re: [PATCH v4] mm/memcg: try harder to decrease [memory,memsw].limit_in_bytes To: Andrew Morton Cc: Michal Hocko , Johannes Weiner , Vladimir Davydov , cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Shakeel Butt References: <20180109152622.31ca558acb0cc25a1b14f38c@linux-foundation.org> <20180110124317.28887-1-aryabinin@virtuozzo.com> <20180110143121.cf2a1c5497b31642c9b38b2a@linux-foundation.org> <47856d2b-1534-6198-c2e2-6d2356973bef@virtuozzo.com> <20180111162134.53aa5a44c59689ec0399db57@linux-foundation.org> From: Andrey Ryabinin Message-ID: <8f706bc5-cc9c-01f5-1918-41cd0501f4f0@virtuozzo.com> Date: Fri, 12 Jan 2018 12:08:12 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <20180111162134.53aa5a44c59689ec0399db57@linux-foundation.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [195.214.232.6] X-ClientProxiedBy: VI1PR0501CA0013.eurprd05.prod.outlook.com (2603:10a6:800:92::23) To HE1PR08MB2828.eurprd08.prod.outlook.com (2603:10a6:7:2e::27) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 5009aab9-27ea-4f9a-1655-08d5599bfd3d X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(7020079)(4652020)(5600026)(4604075)(2017052603307)(7153060)(7193020);SRVR:HE1PR08MB2828; X-Microsoft-Exchange-Diagnostics: 1;HE1PR08MB2828;3:DEpnuiIrToghLqDcLZSXAVA+QQxxunb3arraQrS1NKXs0IdTA3Txwl0lEJ5xRnWWzr/OwUYUmw2R2EbrdDIDqM9XOuYcrKHp1q+1fQ3DcTOozy1ZrgHkZOBYGFjPp29L1YqmJ5WooK99trLicNZXIKh2ItS8sAKtGulokekylEcUnBG7CBBO2uYC4pvtMZLRZ0TeRRsFr9cPtEIKymffzKWe464numME0VreEjWLThbjVNjj4cLYZmImp8t+t798;25:fO+JbWvuXznYjosyexKbKRQpp116HeobGrsBP4hYV1RtdrZ6Kfm1mGR/M/7r0lu2B58zClcXikg4NbojnwPkjhZuE4IMcg+tJE3clC14exfmA9poHJz8T+7rhHu5lRlFmhV6xBdpLqH/cD/icI83dqBR8wJflJ4fM7Vf+SzX3X5/SNj/VTC4wpF4yazCAkB7Rgbdk2qKNRZRgdYkZ+j/dNQzpouTiseSzUBUHtUYdVwBwdKlaAqLsu81+nheffbgM89pszVcwy2L2nhT1F4QNdOWgkINawF3vQ1UBM/3Q37LwZa9uyKBGsnZph04/SMUMzFKVrPU7uA4q9fCwaQJ7g==;31:rrLR8vb4Lg3cY9RXNuvt+OtlOHMjwc8kg7PLh3tAdWYB6rbyNnB/bdeoWvQMyP9bnjRG08pm4KvygX7YVpEVVFaehoMX3SKMIIDZ3328Dgy7n/OKiZAy3pEMFBML4K0dMLN6SFSPQ2r7F+vis997YBOHop+lysbirJ5LSUjvNM55R4j56CAAymm4eNU9FL7I7nkfm0kGFQsoGq9fxJPQFdgdqYi6k+OUjAds6OPbFxc= X-MS-TrafficTypeDiagnostic: HE1PR08MB2828: X-Microsoft-Exchange-Diagnostics: 1;HE1PR08MB2828;20:U7Eu5Vyg1nDvR+MJSHvMT3lceQaF/HhCe+HEV3YveSZBcvh6s2RkpdWVo2gUw4GsbmG6KEmuMjTxu+RB+iuHyd2nL3gWkRs4EUA6wBX/yezcxFJ/B9t251+8QB6A0dA/g0W/M/MYxmo06mtWyl+Cr9jHigHpRayFlpzOcclO/I6Ldd0nbzKaNMmVoMaolT6d2ggE5jFnNpm7Lijaegs2ZCxJlisEd8D6hT7Cl6zRV6tjXq1O0jE+HxXrqgWMhqlpkTj+p32EIWQssYkmT3AueD9TYq5N7CadyjIEsNonNmzuJFdQjG6LKbrr8UttzPS+zPpr8xevIQzDV1ourFGC0O48RPC5ryLdmJJXcUbhsiQSkW7CASFeymUfTOy7w/hrQgpc7IKbLUgpzq3u03A2IMzXKb/QCxahE5NaRAKlyh8=;4:t5oV6ytw6gHfn5J5PaBGyI3F0BH96OJGyvmr1FNKSsE06sPzqqDScQkrVLRWuvlWR99N1M8UJtk6/+8msq3eZsc+umR7eJwDQX3YJLfw+Um1HVZCDXhrP319pd0O8f+owff1n6bPALnPLo+02fuk4ktCLyL3j9Qm4xh18aL7K7BBqNDWtmL/4/yO7RN9nZhRmJjsD+p7fYofsHMYvdAW5+WyGYIF0v/9moVId7jFDhLIdpYcvdXnMtJuLKO3YBekhCqPZ/Mpg6WSKZlK6wK3hw== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040470)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231023)(944501141)(3002001)(10201501046)(6041268)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(6072148)(201708071742011);SRVR:HE1PR08MB2828;BCL:0;PCL:0;RULEID:(100000803101)(100110400095);SRVR:HE1PR08MB2828; X-Forefront-PRVS: 0550778858 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(6049001)(39850400004)(376002)(396003)(346002)(366004)(39380400002)(199004)(189003)(24454002)(52146003)(64126003)(2486003)(2950100002)(8676002)(53546011)(7736002)(3846002)(16526018)(31686004)(4326008)(59450400001)(386003)(25786009)(8936002)(36756003)(230700001)(6246003)(76176011)(305945005)(39060400002)(68736007)(2906002)(6916009)(52116002)(23676004)(6116002)(5660300001)(65826007)(47776003)(81156014)(86362001)(66066001)(478600001)(97736004)(106356001)(50466002)(105586002)(229853002)(65956001)(16576012)(53936002)(6486002)(65806001)(93886005)(81166006)(31696002)(77096006)(54906003)(83506002)(316002)(6666003)(58126008)(34023003)(148693002)(142933001);DIR:OUT;SFP:1102;SCL:1;SRVR:HE1PR08MB2828;H:[172.16.25.12];FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtIRTFQUjA4TUIyODI4OzIzOlc5L0VzVXVYeDJnbVQ4dTNDOHFsSnJzYUR2?= =?utf-8?B?d1RuL1dIeVlrcUxwaGtlMi9MbkxDTzVGdFdmZGl5cU1wNWhMWi8zUlU4OG9x?= =?utf-8?B?SjV4Z0hFeW9NRlBETFBOSGZxVkpKQnNyY3htakY4MlF3WXhCSkZkeEFjVm1Z?= =?utf-8?B?Mjkyb0dyU3BnY3JRN2dFUmxIbE9VTmJsbEdlK2g2ZzJtTW5Uc3NVVXNMUWh2?= =?utf-8?B?WERtSW8wWUkvUjg1eE1EUDdTMEw1a3JlckhYOU1YZzhzVlNLdWg4OWtma1o1?= =?utf-8?B?OXV5eHZ0ZC93T3lQcU83QUV4RWFkOHhEWk5tRVorc2tPQTlvQ20xcWhZY3d5?= =?utf-8?B?K2lLa1Q0b1FhU0EyTENrMUxmeEY3R3IrQjNBY1dESm9yWWtaZ01xRzJic0FO?= =?utf-8?B?OW1XaS9rM29NK2toT1cxZDM1TkVvNTVSQnBPQ0lLY3JLOS9HYy9LcW9yS3pC?= =?utf-8?B?QUlwN280Tnl2NjBabXVHdWp5Y1Vyb1UxalcvMml6ME1KQXo0dk1zRC95cHNv?= =?utf-8?B?T0xyamhmemUvZ3FKVFc5dkFrNGRVci9pM2Q4c0dETHF2Z1NlUG9CNjlrRmFD?= =?utf-8?B?REhIYTY1dWJJdmovYjBMdklrZDgwQTRnZ1RRZThJREt4Ym85cVM4VmQ5MUxa?= =?utf-8?B?bTgwajdKTlg3cm1XMSt1OSszdEdYUWhSRGdaV2ZqTThZbkVIV010aG0xRjJx?= =?utf-8?B?T1QrdENnMDA0NjJpWm80bCt3d0REcE52SXZDTWxGd004ZzBrd08xMGdDd1Z5?= =?utf-8?B?cU13MlBpdDFiQmZ6dHR0elNXb1RoaG9yK2VubkdESDJZYmIyQW1pT05KUDZC?= =?utf-8?B?MHVKeWlDd3c3YzZGd3JFUGZESUN6TDN5RXU3ektQdm1HcXluV2dHQWtCOFVI?= =?utf-8?B?V0IxYjNxRzVOUlZ1VmZCcUN4Y0E5UTh3N1Y4N0FNRDJ6SDNObmd3dVJ6bEJz?= =?utf-8?B?Rm9Wc1YvRmVxbU9qTkYwa3BQc0p4VjFwMGg0TTdxNCswenlFYVhiSkU3SkdE?= =?utf-8?B?MU13Q241U3Q1THZrRmNXOUdlb2t3QytCcGNRWVZjNlFiYXUvc2RwU2NJeEg5?= =?utf-8?B?SklHM0I3c2l3WlFoNUVqTDRmZC9WQ3Fmcm9aNW51eUl4dUZwczVNSlNiM3RS?= =?utf-8?B?MHVscHJsVjBWWWVhMGY3ZWFyYkRIWElWQUY0MlNPRXJ4cUZFWTBMYWZNWXNE?= =?utf-8?B?Sm8wMHhwTEtjTk51SVN3QnN5Y1FRUWV0MDhDQkdxZkJtV1kwNWlFL2hXV2Z0?= =?utf-8?B?SloxdUQyRUd4MTc5YWxPQWZLMTU2NHpWUVpMWk1QZFZjWWZKRU1NZVJUOGRj?= =?utf-8?B?ZUVDN1krS2FsYzdJOWtCSUo2KzVSS2hIRUVhZ0szVFJhTndWRm14dXNtaVF4?= =?utf-8?B?YzJGeU4xTDVyU2tmL3J3YTdBRi9tV28xMnBNNzNCVm1xbkxqRkxsMFlKQmRZ?= =?utf-8?B?MWZWOWJSQ3RCWXdpTUM5UG5jV1F3bHRTWUl3MWNPa0Fua29iSEFMc3IvWG1U?= =?utf-8?B?VFJSZTNvSmIwSEtwWEM3ZWpwR0ZPVFRpTEIzOGE1NXZHbGFhK3pTejFqVnEv?= =?utf-8?B?bHBLWjdCWERJUXhpZ3BXYTBPeStyV01VN3YwTU10NjB1dzZNdURSOXRMVVdI?= =?utf-8?B?QnFMWjEyZ3RIaXV4ZWVkRTUzenBPQ3N0QURaM3lkMHRRZzNvbkFBeXFtdFFj?= =?utf-8?B?TGEwdENqRDlZTEVBcUZxdDljS0tlN2JCRHRYTlY2b3h3VTVoblNsQ0NwQ3lo?= =?utf-8?B?Smt6cWhGUFFqWnpRVThHUVBpSHdTNXU5ZWFLSkpuTU5LM1FabEl3c3MzRWZ1?= =?utf-8?B?d2lhbDFteUF1eFNnbWdxb3ZWaXQ2aHk2Q29pYkZ2S09Zb1Z3My9tcEU3Ykhj?= =?utf-8?B?N1BFaGpGblBONjVvM0thc3JTRnBDYUVGVHIzYzU3Z2c0bXFkWktuV3UxVjkx?= =?utf-8?B?ZHR3S3JEbjJXNTBzbWdRZVlSU2phY2NhRzZ5UlJNY0x2eW9XR1FqT01JbjdH?= =?utf-8?B?NXZFV0NFSDhZZ0d4V0lPeEhWUEJNQ2Y0VFdMVFBmLzZWZDBhMThkRnpDK1Zk?= =?utf-8?Q?MC3Q=3D?= X-Microsoft-Exchange-Diagnostics: 1;HE1PR08MB2828;6:cGgHeJbj/AihenKfkPWLroLgPZb2r1HElghr2+j4oJQ12+jYle+fUodyuqTlfFVPO+U2rvSw9IOW79Uu8ErAWxquAqHZuSGXHDR5qaQpBk1+TYCQ9JajtXSBrW80jYgQoSXr7FbQ60OEKEMQyXL55DmnXOUtbI+kveTmM/cktuZHsOjYn9AK82hHUf3TKbuoB78LrMafcFIk05RG8JCPYei1Nts2csClZD7PlkyIoyt7e0aGXNChKVZBbYneeJl5ZLyrjKAkRiDdciL+qLriAhD4afAcieX5jsXRYG0J+SAAnfkrn+g4Gn5tI7l4XUrmqgspgMhVOmDnRnqj++9jJkJjTam41NHpifOnVFhoUmk=;5:isTjUoohiiYTTPz6lfiHNwV0ehOCOlQTpkDBU7lDtX9zq2rBS8SK0z5xSZlqjwT73UXxlFqA7PerplvJyUG/wjC9PyJYiHHeYf6Qv5sJD1GrqiC6nL3Eb6cq6Xb6wHujXjEnOpJ8nlweV7F7Nnd2RbbbKNF6PKqhTQeAXKI9kzM=;24:KXAVftJCkfZgwf3lWDZz6T7QINSUKzQx8TEJET8YD5K6ZVwa+s1x2PcXvvSsfu5zmK7CGOCqRAbhLO9/HhVFMmwtVYI75nkXFpMOllLzvYs=;7:oX3A0pq4+dRhwgNnLCuVL3NLB0cJEKEXlEaGiaDndJDpUqUIC9ZZWFlRiodG+qJh0kw7ZNnN+soHy1DIenLqtNjI2BwAom0KPQ+9T+/20PnkKuf/0X8hFTvCdQhp/dFPJZdayxCNjwNSK6qlIZKW5G6t2Wota4/ATTGQD8Cz56K9MuQiXak4sTbXGVTB2BRrk9RZyXFOiAQ3tihlTv5qggEqygpuYL9ZVIolvSvG4ALkPZy4f9JCiZ3QDptoO2z4 SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;HE1PR08MB2828;20:5emYQ58W0HdL97QNx/2MsEVhtDiHEkeCcVsKKtT/Hza9j5xs/8ZxIKS3xErnPHQHh1otn2CxOIYElI24BhWsjZNmhOozA9a89VTYla0U18YDzCy8cHHt5u/7yxZmey1ybQUsC2M8PtC144KpgnETtGLqh7Kz10G6ehNnj6qhiNo= X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jan 2018 09:08:03.6391 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 5009aab9-27ea-4f9a-1655-08d5599bfd3d X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR08MB2828 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On 01/12/2018 03:21 AM, Andrew Morton wrote: > On Thu, 11 Jan 2018 14:59:23 +0300 Andrey Ryabinin wrote: > >> On 01/11/2018 01:31 AM, Andrew Morton wrote: >>> On Wed, 10 Jan 2018 15:43:17 +0300 Andrey Ryabinin wrote: >>> >>>> mem_cgroup_resize_[memsw]_limit() tries to free only 32 (SWAP_CLUSTER_MAX) >>>> pages on each iteration. This makes practically impossible to decrease >>>> limit of memory cgroup. Tasks could easily allocate back 32 pages, >>>> so we can't reduce memory usage, and once retry_count reaches zero we return >>>> -EBUSY. >>>> >>>> Easy to reproduce the problem by running the following commands: >>>> >>>> mkdir /sys/fs/cgroup/memory/test >>>> echo $$ >> /sys/fs/cgroup/memory/test/tasks >>>> cat big_file > /dev/null & >>>> sleep 1 && echo $((100*1024*1024)) > /sys/fs/cgroup/memory/test/memory.limit_in_bytes >>>> -bash: echo: write error: Device or resource busy >>>> >>>> Instead of relying on retry_count, keep retrying the reclaim until >>>> the desired limit is reached or fail if the reclaim doesn't make >>>> any progress or a signal is pending. >>>> >>> >>> Is there any situation under which that mem_cgroup_resize_limit() can >>> get stuck semi-indefinitely in a livelockish state? It isn't very >>> obvious that we're protected from this, so perhaps it would help to >>> have a comment which describes how loop termination is assured? >>> >> >> We are not protected from this. If tasks in cgroup *indefinitely* generate reclaimable memory at high rate >> and user asks to set unreachable limit, like 'echo 4096 > memory.limit_in_bytes', than >> try_to_free_mem_cgroup_pages() will return non-zero indefinitely. >> >> Is that a big deal? At least loop can be interrupted by a signal, and we don't hold any locks here. > > It may be better to detect this condition, give up and return an error? > That's basically what how v1 worked, "if (curusage >= oldusage)" used to be the way to detect this potential livelock. So we can just go back to it? From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrey Ryabinin Subject: Re: [PATCH v4] mm/memcg: try harder to decrease [memory,memsw].limit_in_bytes Date: Fri, 12 Jan 2018 12:08:12 +0300 Message-ID: <8f706bc5-cc9c-01f5-1918-41cd0501f4f0@virtuozzo.com> References: <20180109152622.31ca558acb0cc25a1b14f38c@linux-foundation.org> <20180110124317.28887-1-aryabinin@virtuozzo.com> <20180110143121.cf2a1c5497b31642c9b38b2a@linux-foundation.org> <47856d2b-1534-6198-c2e2-6d2356973bef@virtuozzo.com> <20180111162134.53aa5a44c59689ec0399db57@linux-foundation.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuozzo.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=J/EVSyLmUhrzuB9g5gH3Vl6gxKd4rYpTfKWKWiJtsb4=; b=ZPkk7jt+jzaipnBPD6u9XwCmbI5vbiAhBim7yCtMgvu7rejvJfDk8zJonS5zOR/rWje/vbmdFF56hv5ac00sSJXr4s4HGvmNGcb/qsxCwf4E9Vljw124g/eQ12qRHn/yeAT+CzLKvmqkeYKrJKRvfpxVjTtYszJxBEodyaaAxxQ= In-Reply-To: <20180111162134.53aa5a44c59689ec0399db57@linux-foundation.org> Content-Language: en-US Sender: owner-linux-mm@kvack.org List-ID: Content-Type: text/plain; charset="us-ascii" To: Andrew Morton Cc: Michal Hocko , Johannes Weiner , Vladimir Davydov , cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Shakeel Butt On 01/12/2018 03:21 AM, Andrew Morton wrote: > On Thu, 11 Jan 2018 14:59:23 +0300 Andrey Ryabinin wrote: > >> On 01/11/2018 01:31 AM, Andrew Morton wrote: >>> On Wed, 10 Jan 2018 15:43:17 +0300 Andrey Ryabinin wrote: >>> >>>> mem_cgroup_resize_[memsw]_limit() tries to free only 32 (SWAP_CLUSTER_MAX) >>>> pages on each iteration. This makes practically impossible to decrease >>>> limit of memory cgroup. Tasks could easily allocate back 32 pages, >>>> so we can't reduce memory usage, and once retry_count reaches zero we return >>>> -EBUSY. >>>> >>>> Easy to reproduce the problem by running the following commands: >>>> >>>> mkdir /sys/fs/cgroup/memory/test >>>> echo $$ >> /sys/fs/cgroup/memory/test/tasks >>>> cat big_file > /dev/null & >>>> sleep 1 && echo $((100*1024*1024)) > /sys/fs/cgroup/memory/test/memory.limit_in_bytes >>>> -bash: echo: write error: Device or resource busy >>>> >>>> Instead of relying on retry_count, keep retrying the reclaim until >>>> the desired limit is reached or fail if the reclaim doesn't make >>>> any progress or a signal is pending. >>>> >>> >>> Is there any situation under which that mem_cgroup_resize_limit() can >>> get stuck semi-indefinitely in a livelockish state? It isn't very >>> obvious that we're protected from this, so perhaps it would help to >>> have a comment which describes how loop termination is assured? >>> >> >> We are not protected from this. If tasks in cgroup *indefinitely* generate reclaimable memory at high rate >> and user asks to set unreachable limit, like 'echo 4096 > memory.limit_in_bytes', than >> try_to_free_mem_cgroup_pages() will return non-zero indefinitely. >> >> Is that a big deal? At least loop can be interrupted by a signal, and we don't hold any locks here. > > It may be better to detect this condition, give up and return an error? > That's basically what how v1 worked, "if (curusage >= oldusage)" used to be the way to detect this potential livelock. So we can just go back to it? -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org