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 A8721C71153 for ; Tue, 29 Aug 2023 20:12:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D69E68E003B; Tue, 29 Aug 2023 16:12:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D1A438E0029; Tue, 29 Aug 2023 16:12:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C08E18E003B; Tue, 29 Aug 2023 16:12:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id B252A8E0029 for ; Tue, 29 Aug 2023 16:12:57 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 67C651602AE for ; Tue, 29 Aug 2023 20:12:57 +0000 (UTC) X-FDA: 81178240794.02.06E3DB8 Received: from mail-pl1-f174.google.com (mail-pl1-f174.google.com [209.85.214.174]) by imf22.hostedemail.com (Postfix) with ESMTP id 8DEF6C0003 for ; Tue, 29 Aug 2023 20:12:55 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=fi8uyCFS; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=pass (imf22.hostedemail.com: domain of htejun@gmail.com designates 209.85.214.174 as permitted sender) smtp.mailfrom=htejun@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1693339975; h=from:from:sender: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=2c+nAeWfVQ1Bjfr8Iht6NC2EjfJ/cEr0+ZzRbynwAxk=; b=bezGMgBeWFpuj11T489P1NQ59qsKw+4DzwKcDyVDFNzeLfZR+BtzHymXY73dMzsGBUN8Ur hPyE3vYVYajB04oXIioZAv6LstXhOnWKFezOqTqlDYAclIRszKXX9eNfhQOBmifQkqisOc R+iYmTZL+CUeMtoAejRfCOpoRb0K+so= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=fi8uyCFS; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=pass (imf22.hostedemail.com: domain of htejun@gmail.com designates 209.85.214.174 as permitted sender) smtp.mailfrom=htejun@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1693339975; a=rsa-sha256; cv=none; b=3AEJfhOIcm4ezxA2uz6h1hd6258btCF3sKk23My8aJaetI1uHljzGk09Kn5GDTcMe23lXC YgUqFcLniEibtQQvzZSRLfxzt0aM5H8SKvZxBuYHelMblpUVkOV0ORicB/XX4e4FD/jlZ4 /AwxMezHImzqpibSSn/cCWYN0yalyNo= Received: by mail-pl1-f174.google.com with SMTP id d9443c01a7336-1bc0d39b52cso29693655ad.2 for ; Tue, 29 Aug 2023 13:12:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693339974; x=1693944774; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc:subject:date:message-id :reply-to; bh=2c+nAeWfVQ1Bjfr8Iht6NC2EjfJ/cEr0+ZzRbynwAxk=; b=fi8uyCFSwYxdowygceokO1hzxCa6SZcPydHeENoQ6I9i1bCEKoBlmKASSpxIVBLH9N X2SkdZKr8jJuB7Gsm7lNEajsA9sf+SvcbDAt9Lc8zRwFvFeaE5DnAVvB4YyIOz8bY7TB ZYxzjZFDliFAanBgPjkjuoWv8AfooVrY+b5n52GqZFTuSfwF6Xml6GFnVRdvgb61MP2/ CN6cNFQTPe4kqqHsgTJl+milNiiNub3jY60+XhYd6/E25uxPZMg8plrPuiTt1w9vJKDE SpdkPp+isynPyjrLWvdQzcOY8IGo9YkpibVYlXna+LKIlGcb4KDJ8VrmNLI13KeZBmGT eWWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693339974; x=1693944774; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=2c+nAeWfVQ1Bjfr8Iht6NC2EjfJ/cEr0+ZzRbynwAxk=; b=ZovU6xnjFJnz6EK78zWJfwPy2e9wKL+cuUMfqCJjXLf4+fW/tz/LIw0XGtVDSNxi3D GzT5641CyTdvI1w9A0F59u8X1jANeaNOBaOUxnZT7RtOriHCTOJqv47IsU9MCKIGkLZf L++y5Pj2Cwi94TCDcij0D9D8imPEjEFkkB0VhrjatXI7xWP+wteJOy/dHcTfOCkOpuGl T1/VRFpkPi5T8gB4fl2/DB7GCxqjcoCWVInvyS8HkAhZdnjzue1FFVFtnfj3+iPC+YGk Ywl1r4/qiHzvoDQYUzAEARDYNTcJMBiVNnVJMzu4IQGBGIG4O29WzpiTobo/8zM/2zRE MAEg== X-Gm-Message-State: AOJu0YyPFhKpwS6OraFhUwCwB+5GK8dTreRNoeOsPHOX05D5/q61u+0R /1n8Ea/0/1XwLOW6hiKrPWs= X-Google-Smtp-Source: AGHT+IEpUNj7wfCbFVL/mE5P7JQhyEe7o4NWw0E7lHBqGiS/CObrdBpX8m7cFK+x9bfHdypeD0t5jA== X-Received: by 2002:a17:902:700c:b0:1bb:d7d4:e0d with SMTP id y12-20020a170902700c00b001bbd7d40e0dmr109537plk.64.1693339974366; Tue, 29 Aug 2023 13:12:54 -0700 (PDT) Received: from localhost ([2620:10d:c090:400::5:f05]) by smtp.gmail.com with ESMTPSA id i12-20020a170902eb4c00b001a95f632340sm9827265pli.46.2023.08.29.13.12.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 29 Aug 2023 13:12:53 -0700 (PDT) Date: Tue, 29 Aug 2023 10:12:52 -1000 From: Tejun Heo To: Yosry Ahmed Cc: Michal Hocko , Andrew Morton , Johannes Weiner , Roman Gushchin , Shakeel Butt , Muchun Song , Ivan Babrou , linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 3/3] mm: memcg: use non-unified stats flushing for userspace reads Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 8DEF6C0003 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: 8er16jr7qkuwioeoeexn37fwiodu1ddg X-HE-Tag: 1693339975-672767 X-HE-Meta: U2FsdGVkX19yJXGcJiXUIBc+e+1q3zJI/FyuD71HgSicTr27letTRvwnDGElhNSZw9NuMAWF5GT6ZzG/Qme0jY3GvGdZ5MmtTCVeH+eggnhxpJiQPW/WW4+eq9XT9LSp6cQGqvw4Ch3JOjrSGHsA0Vo1uXPttvPls9p3wttcTVAQcOZOg+Lal/7O7nsQg4YMelqZJVO1P6VwGePNsXICG/DRJmDebE477+Xf2euCd/Z2HtoMLYeUvqR7bWmg1+mHb3u00bza11p1loP0t8q2COEHKX6N6r6GegUBsm/QdFDh6Cv4q4ygsDqU3FFz9ReSjCtZ7tYuVOpAci5dAvBCw+k8S2xLpEDu2eSIH7obWwwlvTr7Qc9V7zFRNpmwKzz7V/LYNVHjLg8m52xEJgf8ag0Ay2Aa28SYTqwiD+hHyS741e1oUO2ZjCsB347XlQOgCYRrkhQUjbLNSJP6kLbR1EHxJDo4sMBMN7cAYJbIsAsSE6OKjzm8NTZRHQKVXTwSPS7fwG7rf+Hy1t3v+gBbL5h2HxuXvX0VSNa8Le1ClPjJM46D7JADtNCjhC29LNZkiqWTpq4E91BVUW75SOFTgkphtWzKRSrp69R5pCSxldXB3ywOYuGGzwYztbzdtiDEMHauNWpVgYlbyYAZPH1PA9EI0yJicuL91H3TiikB6I2ZJb40Q8IghbPSZML21f5cwcPHE+vRG1YNCQxEM/P5hIhX0lv/r53Y0XlmdiUfdCBZ1NhS+RdIzeKKfurEay8duD1G+8IKYhKq1TnrzPa/opYOrJuOToLELzykHnCRxB6Cvdizgtf3GarE2kSaRzoApieSWWTD09W3cHLSn6AH90962Q1AO0ElaEXzbWwH3v13+2MlpunUReO/MTyptDj2DvZ4dw9vJFDzwMm12R/dqL6auygpaFb6KdBZXzPclTB59/EEwU9afrdjGuuFNnFaLtlyPGsmR9UKNul8biX GO1UZYTp S6wj3tlcL/O0RNcJRrefGrsDkcNHGBh+feHJ4TuEnCvjFP0HddjgH35KEzpaITN64VhcCYVz3RdrgDjU5ZFm8LfaUJVYgdAkHd8Ijx6wMsh8cubZ9woMg7pICkYdSIl3YTSfzehdAeQGD0EmHtXmpzwoT97sZpUD43jWDAow7FmeCBI8+fKSRMMb14fcN2+gA4s6MnEV0vRxojjIqmaOGpjQg+zGmZ5a4S+iewqYmVhyZHYFYHgStOybxQhSJM+CtLn59F4c6syTdPstDKxOmGFddsNusVywhc70CFeAqdc5f4u6zY0BpFWz1fkrAy3hrfmvzgYfDBd6ITXKArirkc60SdeZeQBzYb4oRtC+zg7+ZMCJSfXwFFHIR9hStaX/9pv5kBZ4np0uZ9aI0SKFdqXcnfur8nKlMyd15dL041PxXd22Lwq0ZJWo8awRHUFugn/YuXwmqqHEJurjdqIGK9n6XFW6AScjlY7Cc 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: Hello, On Tue, Aug 29, 2023 at 12:54:06PM -0700, Yosry Ahmed wrote: ... > > Maybe leave the global lock as-is and gate the userland flushers with a > > mutex so that there's only ever one contenting on the rstat lock from > > userland side? > > Waiman suggested this as well. We can do that for sure, although I > think we should wait until we are sure it's needed. > > One question. If whoever is holding that mutex is either flushing with > the spinlock held or spinning (i.e not sleepable or preemptable), > wouldn't this be equivalent to just changing the spinlock with a mutex > and disable preemption while holding it? Well, it creates layering so that userspace can't flood the inner lock which can cause contention issues for kernel side users. Not sleeping while actively flushing is an side-effect too but the code at least doesn't look as anti-patterny as disabling preemption right after grabbing a mutex. I don't have a strong preference. As long as we stay away from introducing a new user interface construct and can address the noticed scalability issues, it should be fine. Note that there are other ways to address priority inversions and contentions too - e.g. we can always bounce flushing to a [kthread_]kworker and rate limit (or rather latency limit) how often different classes of users can trigger flushing. I don't think we have to go there yet but if the simpler meaures don't work out, there are still many ways to solve the problem within the kernel. Thanks. -- tejun