From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 845ECC27C4F for ; Fri, 21 Jun 2024 08:50:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 162476B0331; Fri, 21 Jun 2024 04:50:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 112736B0333; Fri, 21 Jun 2024 04:50:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EF4346B0334; Fri, 21 Jun 2024 04:50:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id BF9236B0331 for ; Fri, 21 Jun 2024 04:50:19 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 71FEFA2B58 for ; Fri, 21 Jun 2024 08:50:19 +0000 (UTC) X-FDA: 82254274158.10.52B712D Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by imf15.hostedemail.com (Postfix) with ESMTP id 53B92A001F for ; Fri, 21 Jun 2024 08:50:17 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=iIhR7FzE; dkim=pass header.d=suse.com header.s=susede1 header.b=iIhR7FzE; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf15.hostedemail.com: domain of mhocko@suse.com designates 195.135.223.130 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1718959806; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=4IBFY55aY3D9MyZlJoKqwYGdFQP0jr3zjoMUTUGofdc=; b=RwAS6d5sVML+F23I8IewOgvsD98QsDBcTF9mxq4MYKtUCJU+GFwbuzbCcR82lFkfkznafE 5usqwcbK69utivuyRpQZ3gDN9Gt1RztVaa/sMkGKR9kbw2mjIck5GJ09au9KWpvr5IRCdO cz+C1X/B4Dytg+oARfZnskOinj2+hBY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718959806; a=rsa-sha256; cv=none; b=Ez42xHmyPpPpIzuaD2nx6z8OJQs2igUMAeS1o9Y/lNodVL06mbMz7GJAxgD92XEG1bW0CC V3HkCxfhPfQeM9z9HBs3cz+Ev5TK0kCcpUAaabqjmenCwCeH5Lzjx/irkmvQXffCuK08OC atU4NwcnrRuRdoJx8acPsoGBOJLuUEU= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=iIhR7FzE; dkim=pass header.d=suse.com header.s=susede1 header.b=iIhR7FzE; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf15.hostedemail.com: domain of mhocko@suse.com designates 195.135.223.130 as permitted sender) smtp.mailfrom=mhocko@suse.com Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id B147521AD8; Fri, 21 Jun 2024 08:50:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1718959815; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=4IBFY55aY3D9MyZlJoKqwYGdFQP0jr3zjoMUTUGofdc=; b=iIhR7FzEJGs/zGPIlfZppTXopHjXVLCnP5MjHuwuOAum0PiC48QyeuoPLMR3p/C8wndJvM lvAFeNf1QL2ruYvFEsjDPxzW9eJY8K+7Kh6+ucM7F6M8kNamvejRsuWQevL8Nl0RuJ4PLc aRAVIDa1k2Zw2yI1NDBd8l0ajBEycMg= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1718959815; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=4IBFY55aY3D9MyZlJoKqwYGdFQP0jr3zjoMUTUGofdc=; b=iIhR7FzEJGs/zGPIlfZppTXopHjXVLCnP5MjHuwuOAum0PiC48QyeuoPLMR3p/C8wndJvM lvAFeNf1QL2ruYvFEsjDPxzW9eJY8K+7Kh6+ucM7F6M8kNamvejRsuWQevL8Nl0RuJ4PLc aRAVIDa1k2Zw2yI1NDBd8l0ajBEycMg= Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 8CC7813ABD; Fri, 21 Jun 2024 08:50:15 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id ok9sH8c+dWbZMQAAD6G6ig (envelope-from ); Fri, 21 Jun 2024 08:50:15 +0000 Date: Fri, 21 Jun 2024 10:50:10 +0200 From: Michal Hocko To: Oleg Nesterov Cc: alexjlzheng@gmail.com, "Eric W. Biederman" , akpm@linux-foundation.org, brauner@kernel.org, axboe@kernel.dk, tandersen@netflix.com, willy@infradead.org, mjguzik@gmail.com, alexjlzheng@tencent.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v2] mm: optimize the redundant loop of mm_update_next_owner() Message-ID: References: <20240620152744.4038983-1-alexjlzheng@tencent.com> <20240620172958.GA2058@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240620172958.GA2058@redhat.com> X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 53B92A001F X-Stat-Signature: xhmp33sr8aa148zpfte55mixpgwgfc5c X-Rspam-User: X-HE-Tag: 1718959817-357560 X-HE-Meta: U2FsdGVkX19zVXiFXkznbJeZT0M5J1d7/Y/YVAyZURzJTogEebgQt1ot5IwGeuhAjrw4xLUhxK62IpAcqEyCGqfqrBdI4NcRbI1sUk+1Ftg8LqtjT9oliFh3zfZwjeztf7A8eo2sNgzyLsxIQ7P0hOE6PbXPpZ8AKmQmeKY58c3YTqHmrhCzQWc86lSgL974499o88OxGDBJRoFeJwbKrin6JdkpAkrW6qm76fE6YmYS0RyBRi4C9JUcs4HwE2JNLvurTsxmf99p20Kz2CMtMnr0vwsZyAv40+UHyGBe+j6XIY3+v/DFzxGpUkrrubRqNNVI3GLCzgMv6kkIq8I5S+zei5qS6pfQmdw6KxVa3ZVTFen/yZXJMemsVv7Z+4jHjUwqiIEyrVLRYqAsZ3YAxrvXYVtNxMvyf0kkA/+glj5pP/2CMSD+zAs+DjNMmSpCeUOLyqB2sq3suO4x0DAlD7+lqwF4bJhOtCJWlj3XuHccBCyeg94KqBJneCoO2f596UG61Yl5gNFyLCvvxTfAWHsARxthrYhBdGxOVa9i9D7li2GIvFBOw4rqg0Vndi/4+KuhM3dJ01Dv9oc+2rH0rCH/+coaaoQTxnsIEpoPsgUwYckwcJkRxLoBwKtMWJsVuHzVkrhF7dpCyYCORqiCZFSm4TaKmz/vCcE7T68RqKYXrUwR9U1dEgWq+NZvi7sAaoCCZRSd5aCdeV7JRrzAqsVWinhhRWvUJ6jjrOiWKY5vhllCQXI9wqmouwKJVcL6s/hDdSa+VsD7Y9pT9BJPx/wvrDcfvaI+mo5HIQKI7FNTpwE1/DegTv8iVK3orKLk2jz6AUYoipuvG7p50wUoh6OzJCGLnJGeDZ1KfB8NGdmA2B8UImuWEfmMtEocqwrQjBdKTs3z8VV/XbS3yBt111rRff3LctqY6ywMXwa54HgJA2nlmVXEJSJIYLLTyAfzCKnvpoFloZQOsf/UkeK tWNST3ph p8c90NPsMyCOJqCK5al2O0OXAL9PvHvAQ7u9JRf+1+gmQrxSCjSKYWdjyiN0W5VFWba+C/seKIg1e+Y2mYcHrbMV1gzkYxNuTlAqehAL8a8YHS7U8MmULU3rxxMUS5DUnP+2vpyp+WsilFcdDMADi9i6UhJlcNKJ/7VLgOUsaAFZA40O8QUNExw0orANP1tpiG+1UxCNZ/AM0bO5EQuXS5fY3WGM07HzdoQJSx5RBOUzy5lVS3/8+x9cGXPsGG7OFpuEw0twL0GDmHHTIFeYxnmk7w5a7VMd8PDLB0FAWoqPhJUfbWuESP3pOnv7B88k09Zhj X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Thu 20-06-24 19:30:19, Oleg Nesterov wrote: > Can't review, I forgot everything about mm_update_next_owner(). > So I am sorry for the noise I am going to add, feel free to ignore. > Just in case, I see nothing wrong in this patch. > > On 06/20, alexjlzheng@gmail.com wrote: > > > > When mm_update_next_owner() is racing with swapoff (try_to_unuse()) or /proc or > > ptrace or page migration (get_task_mm()), it is impossible to find an > > appropriate task_struct in the loop whose mm_struct is the same as the target > > mm_struct. > > > > If the above race condition is combined with the stress-ng-zombie and > > stress-ng-dup tests, such a long loop can easily cause a Hard Lockup in > > write_lock_irq() for tasklist_lock. > > > > Recognize this situation in advance and exit early. > > But this patch won't help if (say) ptrace_access_vm() sleeps while > for_each_process() tries to find another owner, right? > > > @@ -484,6 +484,8 @@ void mm_update_next_owner(struct mm_struct *mm) > > * Search through everything else, we should not get here often. > > */ > > for_each_process(g) { > > + if (atomic_read(&mm->mm_users) <= 1) > > + break; > > I think this deserves a comment to explain that this is optimization > for the case we race with the pending mmput(). mm_update_next_owner() > checks mm_users at the start. > > And. Can we drop tasklist and use rcu_read_lock() before for_each_process? > Yes, this will probably need more changes even if possible... > > > Or even better. Can't we finally kill mm_update_next_owner() and turn the > ugly mm->owner into mm->mem_cgroup ? Yes, dropping the mm->owner should be a way to go. Replacing that by mem_cgroup sounds like an improvemnt. I have a vague recollection that this has some traps on the way. E.g. tasks sharing the mm but living in different cgroups. Things have changes since the last time I've checked and for example memcg charge migration on task move will be deprecated soon so chances are that there are less roadblocks on the way. -- Michal Hocko SUSE Labs