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 C56CFC4345F for ; Thu, 18 Apr 2024 14:49:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 415146B0083; Thu, 18 Apr 2024 10:49:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3C5BF6B0085; Thu, 18 Apr 2024 10:49:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 28CE86B0087; Thu, 18 Apr 2024 10:49: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 097B66B0083 for ; Thu, 18 Apr 2024 10:49:19 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 8166040FB2 for ; Thu, 18 Apr 2024 14:49:18 +0000 (UTC) X-FDA: 82022935596.09.BE42C75 Received: from out-188.mta1.migadu.com (out-188.mta1.migadu.com [95.215.58.188]) by imf14.hostedemail.com (Postfix) with ESMTP id A3DD210000D for ; Thu, 18 Apr 2024 14:49:16 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=iEARRixF; spf=pass (imf14.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.188 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1713451757; 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=L+oZNHCiAYDQYgTy7C1ugxmdQ034rdJRx6SliQtfo3k=; b=3Wf4N5FMPJEuVS1OW/5JDSB5Yeu4LBXxxVoTgubraJ5HcgdedRvXEcuK6EoTj5FRtIM7t/ i7XVdEP/6QlB0uur3hLPPFX3pvJFMrkuIGX+TVyzriTvGciQlp77VV8AObPbw8bwW4uhaZ MZjlDfCdNWzk3UEcvfQs+m+atqsKFF4= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1713451757; a=rsa-sha256; cv=none; b=yk9hpAsTsBaPE1dYAnrF9I4b+YzzDJheMVbmqIxrjFfp32/KtJwQt+P59NOFnTZaQDcu7l xfZ9duQWQBu5yMcmn1o9G7U19JfCaZyD62NO9NQt5nXoTMCC1LcryhJpuSx9EpiToK2FiD qV0FcOnmfoBPmOcsi6jeDkcSMLBO4X4= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=iEARRixF; spf=pass (imf14.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.188 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Date: Thu, 18 Apr 2024 07:49:02 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1713451751; h=from:from:reply-to:subject:subject: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=L+oZNHCiAYDQYgTy7C1ugxmdQ034rdJRx6SliQtfo3k=; b=iEARRixFPb7tY694aPQ7hwwXPQqJZftXCopWiRG8K7LuZOlONNwzObwH4juZlvCU8THu3g hivCPVdZKszLw3dA047mPNFgYGE0J5Y2chC7EIdAfCoyR9ryDC++O/Q+t79Fn8O5v6p52F +WXAeQRqDuYsoq2y3t68OFrSNJUIJrQ= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: Jesper Dangaard Brouer Cc: Yosry Ahmed , 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 Subject: Re: [PATCH v1 2/3] cgroup/rstat: convert cgroup_rstat_lock back to mutex Message-ID: References: <171328983017.3930751.9484082608778623495.stgit@firesoul> <171328989335.3930751.3091577850420501533.stgit@firesoul> <651a52ac-b545-4b25-b82f-ad3a2a57bf69@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <651a52ac-b545-4b25-b82f-ad3a2a57bf69@kernel.org> X-Migadu-Flow: FLOW_OUT X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: A3DD210000D X-Stat-Signature: 9q4g61uiwfzydsdj56rzqked6yu5di88 X-Rspam-User: X-HE-Tag: 1713451756-524448 X-HE-Meta: U2FsdGVkX18U1CgaGnPY3atEualgQEbfHGK7IPGD3o/Y/hDPviUb0d/rmXDM4nJkUDpBmDjBopmjH237dYGx+hlQKf3VOS4XP6ipJZpMAa9a5mTc7qdJdHdqIXZq1bvX923uINhevEk/GOwK6qmgI6VBGXaNBc0c81UfLEtuY8ePgyfP6gco2okiImjO+HVoC8+hZCV5axt6K7I2cagapv92aFXDdeHWx/0T32moevkEiwHhM1A3F73Ze0gzzdRhENMVGEhUuMaHpK8RpNGogDAupL1p3DarvkgYs6Ef3vxwmqROJQehyZOGXfMlWQRkcGOo7MfDUbMJATzSjV+k9/hegBOMR3Hu1KNR/F8YEP3sJt/bn3/Z00f4/hi58dv965kFmMqnVpVrIH3vwZ05MY1M9oh4rv7V5AkDdXX+LoaudGrEFgXUrZiTSi/cw4gFYfdLVeOyl7pzSAkoAGX/ZDyEs63b53DJ4XXbw+m40DAZ9WSitjduu5TmPOKsTz+v81QFBT0fueWh87meaP5zpeyXkfa/jIF2Yp5sFNGatcx2m710y4mpwslPttJOK1Jo3U8gOnByJZV0i5/ySjO7XzJxCsEhzNI/LiKRxYR6VDITTjcaZad5HG0xuw9w9KRye57HZEZ7Ag4+xa5d5KSysyPCpx+kGvVlbWiEiSmFMoYpIat2XUfwgFxQ+Bqy2BBCEYHDYzWrNikrqxWdR8DlaUXRckRzOlSmcDt8P4FGeat4oGf/zuB/ETlCDoXOEm7oBSwoXzWC4Ak4ZVPBSI+uqaK2pYBjV+cPRS94it7Ch1JF2zPOweeBhz04i3Eec/zGwO/3Hjkkl95HQVtGH0nlczV/Uk4zsvVNduYOQ7Ssri1sgjcWGojUETmwW01n4lkK46ikYKLcB8ed2M3Gz5bsWtXzRmKidmRFYDYOQcJSxs/vOG87LVzmSf53UT1UXnex8I/GmF3Smj73cqXpE6Z tWQ21fp7 G2mautF1zWFV5Sbb+vpWWAhwM6vL0YbqY7ZxRy/orF/vo9dhJGoVYaMYxJbyIyM3O32oGNr4fPzFWWTUIY1UWRpIfXRQHnM/+Yu9IKgteoo9eEf8LD1Xa+YcYPUkBp8XBmsTR 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, 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 the > mutex, but I don't fully know the sched implication when holding a mutex. > 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?