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 7B05AC2BA18 for ; Fri, 21 Jun 2024 02:54:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0AA108D0125; Thu, 20 Jun 2024 22:54:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0333D8D0111; Thu, 20 Jun 2024 22:54:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E16038D0125; Thu, 20 Jun 2024 22:54:44 -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 C21F68D0111 for ; Thu, 20 Jun 2024 22:54:44 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 6C3121C151F for ; Fri, 21 Jun 2024 02:54:44 +0000 (UTC) X-FDA: 82253378088.06.BCE29B3 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf28.hostedemail.com (Postfix) with ESMTP id 0E255C0005 for ; Fri, 21 Jun 2024 02:54:40 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=vRD71TOi; dmarc=none; spf=none (imf28.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718938475; a=rsa-sha256; cv=none; b=KJMaxVfV1EqO7hy27ds5Q3wWZEZ2uu+0lDb4Ur78K1YKD+p6DKD/Ph9vYB1PIEhZGcDb0f RKRXWeRVfdG1M4hWKX4UCkgGaXlTygIv/sIOW4bJbIj2RCetZt32valOOAXcTtkorKnr82 TutPMQEUroiLRP0fS9zpZAVKrz36JsQ= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=vRD71TOi; dmarc=none; spf=none (imf28.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1718938475; 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=fL81G7gl5Zr+Kvd8UCiVHcgaaT/y0ItkUHH7Z5emrVc=; b=LZFbJEcSD9T2DmC8/QLf74VHcQbjgRHDqw1dEKjLC1OYFUqdQHIsy9MrnQKCDEe0nnjMMX ymmGgGlA8xo63yHPTjJHV2CDPCXvgsZy2nIodw5rIWRY4rTR3ZxWCT9n7S0FuKKzVrv2cp xaXdg/YTrmuOWhoiVCm2vMhjqRdLtpw= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=fL81G7gl5Zr+Kvd8UCiVHcgaaT/y0ItkUHH7Z5emrVc=; b=vRD71TOiscxF0HN185ld3ufXDx 9uAuIjwpCVjvfxM0iBqgC3ap+DhKsoFKKg5HBr0rPGPA8JgVwY1LvOhyads8p/uSt9G8rG16ILsi5 uINkkdbLL+yVMGpnZ8NE72TiLBPg2r8e0DacKpy8vZwzMv5KNJfJ2BVNPi2k0NjbFnp/+SwgwzId8 Kn6jkoG/UhBNQ0UbvgYbSpcjR9gBhOFHo5CRDGFOtGugETRjgjcmx7vlzL8cPR4hFHIgbHmuxHUx8 iTobtQ5KlxmXypZZD04/R4a2+JfEwmh7vwpD4YFHYTOh9OUxq5Nx5J7TcqArRKg6y+GvCVj9afRrW XqmUfMYQ==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1sKUQ4-00000006j4J-0Jee; Fri, 21 Jun 2024 02:54:32 +0000 Date: Fri, 21 Jun 2024 03:54:31 +0100 From: Matthew Wilcox To: Yafang Shao Cc: David Rientjes , Andrew Morton , "Liam R. Howlett" , Suren Baghdasaryan , Christoph Lameter , "Paul E. McKenney" , Tejun Heo , Johannes Weiner , Davidlohr Bueso , Namhyung Kim , linux-mm@kvack.org Subject: Re: MM global locks as core counts quadruple Message-ID: References: <07e7d078-0c9d-6a1f-1ab5-295f86974b72@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 0E255C0005 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: 99uu3za1bf5p5ys9xi6fo3316thp5hhs X-HE-Tag: 1718938480-512103 X-HE-Meta: U2FsdGVkX1+X8Jb6CI9Fkg2Chs0eMW/ZFkZG/1g6ZE4M9fdCccNrBkmwpxlJJPt3xbWZVhQrBxKazdXF5dp1NZ23hKGjmLujSkTgqzvE1S9pTRlm1If4/T29xG/1XyZwXST0x8aq4N6K++iEXdb1THK/9e9YC6HpStWs1/oklhzx59Q7YZkkMdFqxF3EZ//K5mrbfBTOVyGSn0ugHBd8E7Eakr9SZDh2cM1eVXY/1r14SkRR8MEXkPpKI7AvJTpt8A9sbvIYKo8Nyqn0yEVA7XFEq6VBKMKxYFzOZVzwxcp7u7BXv4O5xiIBoXxtITts6QX8JGEJpxEsJVld1WpDODcLund9PBq0CHJPhhczWt1vxaPtdKUWGxUmpZbvRYX76q/JGAcUrD+LRM02F+WUHZNtZD8bB06BVLDJLeNiV0tBSe9hRqa0bh7xn+ec+3EPXu4aON190q23zC8eys8MWFy4rLBlTLSiX6ugoHIKvQSfvAn+giKcKXgAYkVbjyfx2r63qBiCULtigR6ww3dDSAGA4a/c9fIpNE26zSPcGvTJMUHc6V3J8yxJ4HGfANa3fzc8MbsRx0amMaVhdsUENzgbxn58tWneCABBHy0lcQmdfn+fXHmHpxTue/f+T+KxDFFICU147E0am1FdgDGxW6zIWx6kiufAu/XGXph6YwDI2KB+w+dcgJcvD0XIgi2CMKOHAiMV4k1ar45Ic8s8ATfHnDKugBeA4a7qIwxyK90TG71wBm53IFlA5//crAAj2bktKG7wWCXA8nknjjJ/KmFM2Q4hvXu3ivJQ1Ej1BuTKgMl4SnJGQ5DDTVJPzOOmrmtWkTWW8S8ofY155dVSpsy4X3iWbExg7tV+d7sIkykx2JSUMTFD+aPoEI1SZ8o6nz4cVVgBhnOI6g30WsrQxcaxXcKgSAFHtPD8SVMvUZkDjelokG35aHTcSJJH/Jg11fFiqkYMiyqfuEdjcr1 eAeUNhDo N2rHHKxLLqU+iVq/BYwKatr6RgJtFY0QfKNbvkdpR01L6NVr6pOrQMRqj+Xqs5fMePuP7n8HPtF9vcqqi6vmC+fKyZUOwM9vYuOH9m2ViYjpjXaW0/50wdhLRbLpoIunMou7KAZl4xyKYZWho48j3y7vWEikGN3pFpHs9B7YdvGjU3/kxUVX15RRz6dagHSN/nsw6VhzM/KBo/tzpZDnlrNtsY0zLq3NFM/nAshYj5TftzFdEj7GLk7PN+9QM7yOtccJ6H91EQblyMWpJXgEdb9TIJQ== 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 Fri, Jun 21, 2024 at 10:46:21AM +0800, Yafang Shao wrote: > > This is only looking at fleet data for global static locks, not locks like > > zone->lock that get dynamically allocated. > > We have encountered latency spikes caused by the zone->lock. Do we > have any plans to eliminate this lock, such as implementing a lockless > buddy list? I believe this could be a viable solution. Lockless how? I see three operations being performed on the buddy list: - Add to end (freeing) - Remove from end (allocation) - Remove from middle (buddy was freed, needs to be coalesced) I don't see how we can handle this locklessly. I think a more productive solution to contention on the LRU lock is to increase the number of zones. I don't think it's helpful to have a 1TB zone of memory. Maybe we should limit each zone to 16GB or so. That means we'd need to increase the number of zones we support, but I think that's doable.