From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932625AbeAKL7b (ORCPT + 1 other); Thu, 11 Jan 2018 06:59:31 -0500 Received: from mail-eopbgr30113.outbound.protection.outlook.com ([40.107.3.113]:34115 "EHLO EUR03-AM5-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S932387AbeAKL7T (ORCPT ); Thu, 11 Jan 2018 06:59:19 -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> From: Andrey Ryabinin Message-ID: <47856d2b-1534-6198-c2e2-6d2356973bef@virtuozzo.com> Date: Thu, 11 Jan 2018 14:59:23 +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: <20180110143121.cf2a1c5497b31642c9b38b2a@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: HE1PR0501CA0032.eurprd05.prod.outlook.com (2603:10a6:3:1a::42) To HE1PR08MB2825.eurprd08.prod.outlook.com (2603:10a6:7:2e::24) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 1837e59f-6c6a-41f1-19e6-08d558eabc43 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(4534020)(4602075)(7168020)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603307)(7153060)(7193020);SRVR:HE1PR08MB2825; X-Microsoft-Exchange-Diagnostics: 1;HE1PR08MB2825;3:x108HKdmFJTlmMmAK1FrEl4tfShqhSBd6V8yPC4YO+Y1qqfJws1qXzgHKoNaGD73awG1ylJ0yl7qKcm36wSKF6uZG/En1bQSwMsP22CJXzmLyvUjKOrjrNqhu7Ewqd2qM3ODd+IOPGaZRL8O5RnGiUBCGJvPQpJo1dnRu+V1g0qalfRRqxfCleSbK5AQbE7orN063GRDcmQY7i9YIkzoaF37+hBtjA3tKn4YfN6/YkBB0W7Fs/+lL6QcEHuy8dC9;25:Fo5m+NBtME5EPvhNdI6vQAZSpzgMxk7AmFG8WPa5UJrr86mu31QGGKnkAODloYvzmdETM6v6kmWcE88GAvHCTJdmBcMOfGUN8FmRoWRHTg1UEw+lgKSv2hN2LLWK8i76JSiPEGkIMOO+jhwruFsXJFIGhG1xt3DSJMpq0HFbiOCRabz2klsruLZxhE1pA+K4/zRAdvRjyOQjVGFmUZsum+W4TQXR0N1nXoYXH26uS1me9AUMo0pQKPI5sFyyvykOGopZdUBcH+P5my6tyCxp25giuFQkHP6rytlO2XNNONFJyDKfkddtE055zzYb+5hsZkJhwLrI3/n5EfGdAU/TqQ==;31:B/2dEdeOGycHYBTAyiplQZrsTSHGvGKZy2EmEKJ4WeLhvVNTH559YMbtfXODc22UupnkL2LhS65CAg/qyFtUuZspN1sUYIaCtA475N8f1kkk4oEDQ1U89xf6IsrhHFf15xxJBHErEWlDH3Pq9Tm5cv28+v7V16s//3OSEHdZJjZgzkAcqqldXRYGEiNC9qHXsA74HDBGzYwja72FR8nCcvlSHEJaav9wNlYGqdg/l90= X-MS-TrafficTypeDiagnostic: HE1PR08MB2825: X-Microsoft-Exchange-Diagnostics: 1;HE1PR08MB2825;20:h0l9hG//PWpybSAvSFofOS6zDDGq6JN3YSQsf/y4Qm4GlKhtdgtY/E7/dSwjcso5K7miILl8Ahhf7S+AZyEobLyfB6iZp+hWw1+gtX2DZ9WkAfwtnC3YNoeOsu/jZY69FyCuS04j4N2U8n9QtZSGUBKDwcfy5JhZy5vqUpJ3I6sptWQ0v6Idf1Wbaa35p+6ONrJg3ESq80pFDDxdS4xLtyamUIQvwuHsVeGZOOYik85LrWhvUKzpHprTb+7l2dr6USL9dZOMA54ntpcUDB76ryQ2mLD2Ba5IR+AyNd1igCjpSqPHr1M0pN4tYiP8dJEvEzz3ni4PKmtSVajyzeDfdhQOUqqYLuoHbDPYoUUpgcUZPB/SldQyYWmiAGXW8Fy12gY4aB1eN/Hr8Qg70sjPVur1KB3rklHUhMz9zEMKfTc=;4:cu7Nwo34C8TXhNjo69vB6Mw5zhZIyX+mRLS/XClwOVLJK0xbx1XDAl6Bp9IUayy42HPZwb9qeO+y6LptEL5907H7T3TaPik1sVZNJZrPS0JCqZY8o/BDDc+WkraCRuNSn50vztL7fcev36E/STENz68JKM75wL7aa0cRDXpIOSQS1taGlnw6SzegzMlu3OjBApxuGaDnaSQLdGmYOwhaTzA3yeRxOdsZnH96I9HyP+x6OIbG0PylthdTpWB8848iKoZw7iloIf2Bx5eMjbk9rQ== 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)(3002001)(93006095)(93001095)(3231023)(944501075)(10201501046)(6041268)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123564045)(6072148)(201708071742011);SRVR:HE1PR08MB2825;BCL:0;PCL:0;RULEID:(100000803101)(100110400095);SRVR:HE1PR08MB2825; X-Forefront-PRVS: 0549E6FD50 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(6049001)(39850400004)(396003)(366004)(376002)(346002)(39380400002)(199004)(189003)(24454002)(83506002)(2950100002)(31696002)(7736002)(6666003)(52116002)(68736007)(4326008)(58126008)(47776003)(23676004)(52146003)(2486003)(230700001)(53936002)(16526018)(6246003)(54906003)(81156014)(8936002)(305945005)(64126003)(86362001)(5660300001)(81166006)(16576012)(8676002)(316002)(6916009)(65826007)(105586002)(97736004)(39060400002)(106356001)(229853002)(76176011)(6486002)(25786009)(59450400001)(36756003)(53546011)(2906002)(77096006)(50466002)(478600001)(6116002)(55236004)(65806001)(3846002)(386003)(65956001)(66066001)(31686004)(34023003)(148693002)(142933001);DIR:OUT;SFP:1102;SCL:1;SRVR:HE1PR08MB2825;H:[172.16.25.12];FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtIRTFQUjA4TUIyODI1OzIzOjBDS0taZVp0WThJUWN0djJMQmJQZ0o1czcx?= =?utf-8?B?WGtKTmhpSWxDdzdveXlENks2V3dZdnBuRUF3VFpYRS90SU1lN0FYcXpnM3pC?= =?utf-8?B?WnlSdENaWnhqZFYvZjBuS05ldDV1cGdRa1BXbjMweEpKb096UkxCZGF3WXpK?= =?utf-8?B?c0JiMW1tY1JUeUgzNEtweEdzcVdINjh2YXduaVdwMUUrOU9aZ21TQ2Vma1Z1?= =?utf-8?B?b2pKS3JvY0V6VWdacFZyV09WenRBNG9oOFh0N0pZVksrZUNJSVBQTGVDNGFh?= =?utf-8?B?ZlIydUtkL284Z0pTVnYyVnVjbm1HSzAyMUpRQW1FR1dPdDEwNEFvRC9XSjNO?= =?utf-8?B?dmF4UnhQandXQTU1THp5MEFkMVY0Mm9VM2o1NDN6dlRHQmcwdm5tTjgyMTkw?= =?utf-8?B?OTQyY2tYMkU5NE9xRUJ6UDV4Uy9DM1RvM0hlQWp6bWdndU9TOFBKYy9QTDZq?= =?utf-8?B?MHZIZ3AzdFVPT3NyS3oxSUxmeDVWVGlkOUdPTkxNeHFHTm84bHF5ZU5mazdy?= =?utf-8?B?N0J5ZEpCTkI3MXFma3ltaTM4SXYzeWorRm43WkJINGdnVlpwbXNiOGozQm5z?= =?utf-8?B?OGZHQVZkS3pxZGxJajNvTDltTWFDcHZwVFplOUtZNjUwMTVncHNheS8yTFJX?= =?utf-8?B?MWczSVpsMSt1aTltT1RucFU5UnNzZ2FYdUhSd0szVWk3M0NLRStYQ3BoWU5y?= =?utf-8?B?Yk1RZVg3akJhcjJZT0tmb2ZXRVB0VVlXUDFETTZackxHUjBzMTdHdTl2Wk9F?= =?utf-8?B?U3lxekxQdXZWYVJtNUdrN3E4d1lWbVUzWitMUkwvMTJTN0JsTUVOV1ZEY2c0?= =?utf-8?B?MTR5aEt4dGlTWlFRRUVtdHhHZXhJNXlFYjVXT3JPYThSZ1oxbzU1bGJ3UDla?= =?utf-8?B?TWJEbjBKam5LZlhJTUV6SmtKSW1GUmtnbVVUTlhJQlRMTE9sUEVHKzVnemwr?= =?utf-8?B?c2dvb2xacGhjWWkwS2tVY2x5eTdWUWR3YlFsYlB4UHBIVHhkdnR0TnhIdlVR?= =?utf-8?B?WFgzYXh5TzlOUysxRDNWTjlrYkNTQit5cHJ1dnYxZnByMzlYRG9TUjhPQVBj?= =?utf-8?B?dEc2UDhPRUs3U2ZjVXlaWnVWeXBZLzV2QkZCWWNRMzlJQmZlOTNVRHFNS0Rz?= =?utf-8?B?SXl3YVlyc1oxeXN5MFdVZ3AzQUdoV0xvbjRCQVlQeXYzVkpvWDJlM29ZWFJk?= =?utf-8?B?S3dkTlVDRmF6a3RnOTJNdVNlVUVzZ1hCbVVZRUtZUG94TjlpRno4MnpUVXFG?= =?utf-8?B?MTg3OUV0dGR6UlR2dlV6aFB5TytMaXdSSC9ZS3dvVWJJdHcwUmNZbGphK2hS?= =?utf-8?B?RjNxbk9IV1hVZmM0Q0xQd3M1T1N5OElVLytHYlc5Y1Q0bytRTVg3TVVCS3hE?= =?utf-8?B?aEluUTloNlYvRU5wQ1ZaSHBRTWFISUNkREVQaTJSdlhmbnhDR0xVQVE4TUNh?= =?utf-8?B?Zm1VU08yZUh5c2R0WkxWTTl6M1RsaEN1bFRFaEVaZWhBWlNIMGlURE1KQUgw?= =?utf-8?B?L3N5ekFKZStKTEJrRnM2ZWVicUxXZUVnR1RiVWt0YnBUcmFGY21GZkpzOGk1?= =?utf-8?B?U1pBQ0JSaDgwcUNBVHJERFpkcWJDNFVXNmVrZytPeFVwTkxNVzM5OHlFK2tw?= =?utf-8?B?WU1uV1o3Rk45aU8waDFRQUtCT3hGRThFS1A3UjJDNU5uckhDaGs5K3FxcHpQ?= =?utf-8?B?dzR1TVJ0MWZ0blRPaFIxMzlhVmxFZDZudXIyMTYzVzRLSXUzeHBBTHRKdXMx?= =?utf-8?B?TytVSFNRQTl4SlhnNEJVL2g3ODI2K1ZDeUZROXZoQ2NLU2E3S3hNc2w2ZEk3?= =?utf-8?B?WG5rU1BCNTErQnY2WWptYjc2YndhMUQzeEkxRXhOa1IwalNzNk5nUHoxL3p6?= =?utf-8?B?SU9ZWE15cGJ0ZW5ua1I1UkVoSDlZczVIaHJveVI2VExESTZYZWRNSExHd2pz?= =?utf-8?B?TTRpSkFFdVloR0taVjlXK2sxVDIxZGxKWTZwRUFuakxvYjRoZ001TCtjWDBj?= =?utf-8?B?OUJkZ3lrZUhTRmtTanRkcVRqRndtaFAvVWd5RE54eGQrb2pnWjkrL2JuS2xS?= =?utf-8?Q?LjIY=3D?= X-Microsoft-Exchange-Diagnostics: 1;HE1PR08MB2825;6:z03/W33fC7yJ7s+tqrdM3l9DsWL2MsJ9da5zRt8oQXAuvJSUjqy7Owc78mVGP392RcWQtLP8aAf/z7ZPffRC7hljwhDN4uRM15w3qyehIDuskcmIN/DEnaQY+1WLInPnYS5JE71Cqn7VE4TyMCYWh+YVD+m+zpLyB35eNvVVq1etl46KnZzsAwudMILS2I8Jy4INGtfC/vjSw8r/WhihHplq6CVjVCIHEfCrZrL7YYFfJWgnokgJgs80SnMJ0DrxQAZrxQaGUm9h9SKsDmmFOIlzcEOF2e8ON+Q8u5cqfPvq5LWeCExE7lndKUQgdl6xZ3wTjPdvD4cbPx8Oeo5m10Uq0a/lnuw5vaoNWVYtA9E=;5:BC9bol8HSD1b67fMUBjlnVODyAZ1/GPBOyjw7hNZByxBDstw4xQ0yEWFSiiIJKBuiEnlMVTNE8U7mX4egISew02aiyLSeAsHoRWYRKdgOPkezpbLRbZsIeHYRmOxpMs13q4fbAJ6Ai9MmyTAtBbVP0svdGbKAWSQ3tw897lXQjY=;24:SUQhyCenfa8zbV/VigK4MFg9dQywcHpZ/W+fjLo3XSwWrPZIhcNln/PpJDN/xLS5ejQ2X8yS9addPL6/3xVf2xZLr9Finv2td64qrJ17ESM=;7:cZjq5HXqli8OgCwTW0s9fbwFMlaylXYNINtKEFv7S+AFczxbbrdsv9kRe3G/T7IURsf3n2+qlCF+iRN1m7yAlOsExFtEpuqKaTZb9pNzQe+RqHkDLH1NwwLg/HCGl/KT2XhFdn/qSOsA3oH/mgjPUmFLrC6wIDWgk3N2BmJkhf3QByOwk+qLuvGFunphZDAPASOTbe9TRbY6gtaO0sQchs+44gBOk0XVLcErdIirjR2oa6Z83pRqT0D3zkhBXFkO SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;HE1PR08MB2825;20:j+xtCbNzkMOsg4+Z1YAyfuu28xXvF5bbf9qh1Lz4uZ73JplbfUBknB+RtIG/lKgZEPL4fniSQGwmMY0/ii28H2MXuoem8erbg/xUQq0KR6zWJwkY7NZ6BSeZ1/DuCjzJEF4zwO0i9/F+OVji4NsKSroT7V4GOAjtiMkvUXn0SLM= X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Jan 2018 11:59:14.3930 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 1837e59f-6c6a-41f1-19e6-08d558eabc43 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR08MB2825 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: 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.