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 262B9C433EF for ; Mon, 29 Nov 2021 13:40:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 89E086B0072; Mon, 29 Nov 2021 08:39:56 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 84D176B0073; Mon, 29 Nov 2021 08:39:56 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7159D6B0074; Mon, 29 Nov 2021 08:39:56 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0150.hostedemail.com [216.40.44.150]) by kanga.kvack.org (Postfix) with ESMTP id 639966B0072 for ; Mon, 29 Nov 2021 08:39:56 -0500 (EST) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 2A4441836944C for ; Mon, 29 Nov 2021 13:39:46 +0000 (UTC) X-FDA: 78862075488.24.CE19F94 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf18.hostedemail.com (Postfix) with ESMTP id DC0664002097 for ; Mon, 29 Nov 2021 13:39:40 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id 004E11FD39; Mon, 29 Nov 2021 13:39:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1638193184; 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=MCR2AjsamUOBWBaNMd3hj2AgMrYiQAsklcYI7+6tUNc=; b=BF5tF/zTTzcePDATMm5ORv0aj2GjCP5cOtzN4OFHtX5kugS+UYnnvq8iIVlAj5+YX67rPU N1SgE1s+MKgLvYeBKJBG8FmbAW4++jm4NgeKnbZN6iYGUrq+j+PdCSs94+YaVrVmeD8r6p 9pOiWBR86RlkVMXhKlBclXTwMIayApg= Received: from suse.cz (unknown [10.100.201.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id C3F67A3B84; Mon, 29 Nov 2021 13:39:43 +0000 (UTC) Date: Mon, 29 Nov 2021 14:39:43 +0100 From: Michal Hocko To: Matthew Wilcox Cc: Hao Lee , Linux MM , Johannes Weiner , vdavydov.dev@gmail.com, Shakeel Butt , cgroups@vger.kernel.org, LKML Subject: Re: [PATCH] mm: reduce spinlock contention in release_pages() Message-ID: References: <20211125080238.GA7356@haolee.io> <20211125123133.GA7758@haolee.io> <20211126162623.GA10277@haolee.io> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: DC0664002097 X-Stat-Signature: kn1594kzyobdmg4baczr9mnsk5ee1r5b Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b="BF5tF/zT"; spf=pass (imf18.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com X-HE-Tag: 1638193180-700942 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: On Mon 29-11-21 13:23:19, Matthew Wilcox wrote: > On Mon, Nov 29, 2021 at 09:39:16AM +0100, Michal Hocko wrote: > > On Fri 26-11-21 16:26:23, Hao Lee wrote: > > [...] > > > I will try Matthew's idea to use semaphore or mutex to limit the number of BE > > > jobs that are in the exiting path. This sounds like a feasible approach for > > > our scenario... > > > > I am not really sure this is something that would be acceptable. Your > > problem is resource partitioning. Papering that over by a lock is not > > the right way to go. Besides that you will likely hit a hard question on > > how many tasks to allow to run concurrently. Whatever the value some > > workload will very likely going to suffer. We cannot assume admin to > > chose the right value because there is no clear answer for that. Not to > > mention other potential problems - e.g. even more priority inversions > > etc. > > I don't see how we get priority inversions. These tasks are exiting; at > the point they take the semaphore, they should not be holding any locks. > They're holding a resource (memory) that needs to be released, but a > task wanting to acquire memory must already be prepared to sleep. At least these scenarios come to mind - a task being blocked by other lower priority tasks slowly tearing down their address space - essentially a different incarnation of the same problem this is trying to handle - a huge memory backed task waiting many for smaller ones to finish - waste of resources on properly partitioned systems. Why should somebody block tasks when they are acting on different lruvecs and cpus? -- Michal Hocko SUSE Labs