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 3B4E7C4345F for ; Thu, 18 Apr 2024 20:40:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A4BD76B00A7; Thu, 18 Apr 2024 16:40:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9D4796B00C1; Thu, 18 Apr 2024 16:40:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 826C66B00CC; Thu, 18 Apr 2024 16:40:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 5C5AD6B00A7 for ; Thu, 18 Apr 2024 16:40:25 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 05568141384 for ; Thu, 18 Apr 2024 20:40:20 +0000 (UTC) X-FDA: 82023820242.27.E65517D Received: from mail-wr1-f46.google.com (mail-wr1-f46.google.com [209.85.221.46]) by imf11.hostedemail.com (Postfix) with ESMTP id 2C7E840007 for ; Thu, 18 Apr 2024 20:40:18 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="tW/2gHcP"; spf=pass (imf11.hostedemail.com: domain of yosryahmed@google.com designates 209.85.221.46 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1713472819; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=djyBKRlGRpWDdeJHGkQSaOnuWsBmFhDAvHccO4EOJ1k=; b=RYM4kYqij819GOe3PrVQ0in1FQuarCARlCivU1u6eyG9DpRdo1EBMxvs7VaTwwAUOe6QiF rOUxah7BorD5ZfTXCDpeHhc5blHiyllCwiXsJxGUJ3qgZewKqW+jL/p9qKC7Q2cwmhMKZX i4eh4MEYLwhEyxOrn6G2ecqv8AZ67TM= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1713472819; a=rsa-sha256; cv=none; b=JihSt14CZuyvCRUyUSZri4J71Cjq4ewjUETsxiNojBPPMEPNImGbtOxV4Vk71xtHBpt0zX vNImF8UnTv52CNNALZvjYsjkMTCVqAWKA6dmqF5ONjpWd9sc2e6KzTxE1u1MSF8DZvzmSY Xm4KnJ+fuMl6GRxgpH6Tm8kvQw1Tz+o= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="tW/2gHcP"; spf=pass (imf11.hostedemail.com: domain of yosryahmed@google.com designates 209.85.221.46 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-wr1-f46.google.com with SMTP id ffacd0b85a97d-3465921600dso1148069f8f.3 for ; Thu, 18 Apr 2024 13:40:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1713472818; x=1714077618; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=djyBKRlGRpWDdeJHGkQSaOnuWsBmFhDAvHccO4EOJ1k=; b=tW/2gHcPcT7RK1gfmuVJRauvM0fc4wNIFBO4xTBbgfPbX3a8FSsF2TrQXRj8iYZM8o rjkDHw9cPQsGamITSBzbEH/HPgqABkrh1ciDdg/4nJXMjQlX0gDX3+t9PtMsV0jQnts+ x8tK7MXwg78gJrRYjggiUMNyyYZXytvD+doqpDOcede+ecu5/rkS2IA5PWmZt58zRsK/ en4MD/LT30IZIqGc+s8RqeYGfHtlnz/Yxj/8Mv2HLEZGDx1xpPnclWQmTH/tnA+6c2VI 5fwK9RovH/fT0Q2zToLSZLYVigwVp0LXCufZJ6ICE0w15IYpswzgeKF6kSWEETwKDcRj aV5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713472818; x=1714077618; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=djyBKRlGRpWDdeJHGkQSaOnuWsBmFhDAvHccO4EOJ1k=; b=RzIPc2ZW8sMmahGjpq9aSU9dGo57u654a86e2Oln2ZKitY7yRrWcgOeHoZExv4a5OL sN2X5J42az1n46ixxtKFj4LUoogKztoUz4mE2twWaeBi1JRlP7bKI6TTOMI/2GWeAv1Y lLgWEF+w0JxJymxDz1DH5vxvf1EXXDkl14g1j84Va2WL9qzyyKtAgeZ9E+fVw5MqXMze MRwu8NwHaVXop3IIAirRacE9buzpEMGgB2yYMdSjGokf+kOB3qXzQm4IMZmM5nnELa6w gzHLLnTYbqP3anDPH35Ztl/2tf2df/mLXeS7W9KYTI1WgWsk0JxlAOXqd9QcnzvZpP1j H2Rg== X-Forwarded-Encrypted: i=1; AJvYcCVoMISb+4qUsN+/upkaJWL3i8gPycQpBiM9QH8B5T4/C85vAdac9sb8JANb8XTcVvbVymz4w932X6qHXEmcc6dO+iM= X-Gm-Message-State: AOJu0YxJN/SY83x1YdjJ3IDh8UdfTIljkjdWUVLnMrcV+Ka9RSS7Rb8a mVcYZ/0ZLe2LqmaPmjWyrqm0b41eWjgNqAbVu0eWU8LrCK5TtM1GpCOs+fdBr+jsRa90HiUE419 BYPL4r7UpYuPPmqi8705SvmCSnwI/9q89BPXC X-Google-Smtp-Source: AGHT+IFo6JA2vkoE/3eFV5S2YO4dqACxa+eCURTAtQHQybTEc66uavOtkJHCgKt+OL7C5O/wtn3rtinJvDxEQsoIiOI= X-Received: by 2002:a5d:6a07:0:b0:343:77f4:e663 with SMTP id m7-20020a5d6a07000000b0034377f4e663mr37716wru.18.1713472817454; Thu, 18 Apr 2024 13:40:17 -0700 (PDT) MIME-Version: 1.0 References: <171328983017.3930751.9484082608778623495.stgit@firesoul> <171328989335.3930751.3091577850420501533.stgit@firesoul> <651a52ac-b545-4b25-b82f-ad3a2a57bf69@kernel.org> In-Reply-To: From: Yosry Ahmed Date: Thu, 18 Apr 2024 13:39:41 -0700 Message-ID: Subject: Re: [PATCH v1 2/3] cgroup/rstat: convert cgroup_rstat_lock back to mutex To: Shakeel Butt Cc: Jesper Dangaard Brouer , tj@kernel.org, hannes@cmpxchg.org, lizefan.x@bytedance.com, cgroups@vger.kernel.org, longman@redhat.com, netdev@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@cloudflare.com, Arnaldo Carvalho de Melo , Sebastian Andrzej Siewior , mhocko@kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: nogj5z3dm31u7pk6dmfssk8nnrhpm3uf X-Rspamd-Queue-Id: 2C7E840007 X-Rspamd-Server: rspam06 X-Rspam-User: X-HE-Tag: 1713472818-99755 X-HE-Meta: U2FsdGVkX19Omnfnzqhpt2FzbskDDy6Y/Wseik3zCo+c3N1PQoctrMQt3olPTAFnNQJYVjoh1y8YLGRen9Zh9aED1YHHPKYuhS0cSYzRQRbkrSlPcN4uKtqXqJvFvoFhNNq99UR/KFetO+laIMfiVnHE3POXm8D0cf6XKJ21OqPq0gok7OeEDaIxvopNrbWZOBPbuGoiM92x+fZEO3tytwQQm8NZ1XNGBDnokwaAQdz9MDj6dnD3vdlFeiCZ1QMvgHUjy0ECbGA+7a6VE0ktfcGu+NHdVydCPjPNMZHo2sgxyrOb8jwYIJTbUlTzu0+jzETpEvoXhv/6I408U4aGHuIc8yaL87ZflH0QFhH+x0Ok5f3HrJjCI6nBIoxF2vnlj7E7FvZnZMAyAwAk5zWFrq5Jgu+tFcHPoYmkuRWgb8pcU3X7EvrHNhrUXYio67WVP7WnpwpfzTaSx2W5e+ZUNAPMTdXZzidx7E+x3KwtRaq4QNXGbJz1PE3g95E+1nmLorFctC+tbqG0YaRbuaOXyFyQrCM3XDbqYVYE33iANT8u9zNe639QcFmDaXxZ4/cDcQLnEMiH7Wo4ZGwwTKZQJh1npLcZ61qQL7d3UQ2lSOw7p3Dy2N/GbTL0VU3A6cQEyK4m22YF0cGbLkPgK2ZVOkAa56orfK5qLtiwWiBaivYCrgo+9p0rZuSXKpVIVTDNWXm0r7mF5tDTaMKTLqJj7YaR4OQWzwj0SjvYG4usdty+WnnS/b93/hLQypBcUSmznSNCCvw2F/BKxL5vq8gj1a7Ng8dC5iCWp8ZAWDJPql4I20WdIrLPwMKydm3mWEdh+pANdXM9JylNnrfkWLXKRE+NPHh29v9DEYJV2I+dZKNCUrBpcqMF+8lfku7ktqj+MnyEu8VDX4JJZpXcCPzetJpGwTSacQEIECkzf259xUdD5bu7VE0OElfq0jn3cLZD6bbYu35x+Y5Zx5NgHEE lcC3J/3B H27fuW5SUWyo168f1pa4/JBCVD2SR3bq5EvtJxOv0ofDDv8H5YbiJ130U7D2lc/rhcdco1VChTZ5SQxICDVbvatczM+59Bm0IHxfF/k431cGPYsUvfb2eRXxXAAFQ2becdAqj7Y76G7CrGjxsSUfXeE9lH+p8y+STk7bhxY0l7NTjk6eY+Wbupxxl8DU/Zjb5ILrs/tLwDLUHwpKYU7W9EfyNxSMUHeLdZZrFmjw+N5YTvuk/wcTaSPa7JEzgvjrVOlsaRFR1hT5a6VSslYLmdfPo3fAAENGn3icoUY+7xZAz0R+1pay0fN+yUrqt4rDjxKoNA5//cJGWQq0F0F8AH4fhsYnw/C1uUr1s20euwey73K/HKGRc9S3EBSL7GkOE6oig23zTVO4SeS4= X-Bogosity: Ham, tests=bogofilter, spamicity=0.001187, 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, Apr 18, 2024 at 7:49=E2=80=AFAM Shakeel Butt wrote: > > On Thu, Apr 18, 2024 at 11:02:06AM +0200, Jesper Dangaard Brouer wrote: > > > > > > On 18/04/2024 04.19, Yosry Ahmed wrote: > [...] > > > > > > I will keep the high-level conversation about using the mutex here in > > > the cover letter thread, but I am wondering why we are keeping the > > > lock dropping logic here with the mutex? > > > > > > > I agree that yielding the mutex in the loop makes less sense. > > Especially since the raw_spin_unlock_irqrestore(cpu_lock, flags) call > > will be a preemption point for my softirq. But I kept it because, we > > are running a CONFIG_PREEMPT_VOLUNTARY kernel, so I still worried that > > there was no sched point for other userspace processes while holding th= e > > mutex, but I don't fully know the sched implication when holding a mute= x. > > > > Are the softirqs you are interested in, raised from the same cpu or > remote cpu? What about local_softirq_pending() check in addition to > need_resched() and spin_needbreak() checks? If softirq can only be > raised on local cpu then convert the spin_lock to non-irq one (Please > correct me if I am wrong but on return from hard irq and not within bh > or irq disabled spin_lock, the kernel will run the pending softirqs, > right?). Did you get the chance to test these two changes or something > similar in your prod environment? I tried making the spinlock a non-irq lock before, but Tejun objected [1]. Perhaps we could experiment with always dropping the lock at CPU boundaries instead? [1]https://lore.kernel.org/lkml/ZBz%2FV5a7%2F6PZeM7S@slm.duckdns.org/