From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 76BD524EF7F; Mon, 12 May 2025 17:24:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747070693; cv=none; b=UHVWWMLTF7TS9Pn7CPXB+rDA8cyph564AYJ5dmDQV//5xbdPyqZ4jae8fpil0XWYnoG/GfI+vohSVpsQGwg8Klc6iJ5/pgEgRr0HLhJ76pvsq/GlzuN/PkWhJW9O1/TvNJVIYKBrKLIvlET8vDO0K0V8NS8HDe1gfjPbmQo5v8U= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747070693; c=relaxed/simple; bh=6TmfCMCAyxoixsYWShG6j4nRgGDyDLi3rtHlHjWz6VE=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=a/y+Ct+SOVJ38HAoCgjfprlSHSQVKRjPQRXuMuQwCvQ8sA9DoK2g+aWVw3r7yOUb9fzUHqfE8z/DWZ5SvY7WkNpHHqzJjM4wNjxD1sYHF7BP0PtMOtYXdmxcE6dnuUAjihvdZTfb3Pud2kRMzacMDwLS7MFLLtEKJjVP3HMOO1I= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 6E14E14BF; Mon, 12 May 2025 10:24:39 -0700 (PDT) Received: from [192.168.178.25] (usa-sjc-mx-foss1.foss.arm.com [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id AFA493F673; Mon, 12 May 2025 10:24:47 -0700 (PDT) Message-ID: <70cadfd8-8d5c-4685-b3d0-23cde6edc522@arm.com> Date: Mon, 12 May 2025 19:24:35 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/7] cpufreq/sched: Move cpufreq-specific EAS checks to cpufreq To: "Rafael J. Wysocki" , Marek Szyprowski Cc: "Rafael J. Wysocki" , Linux PM , LKML , Lukasz Luba , Peter Zijlstra , Srinivas Pandruvada , Morten Rasmussen , Vincent Guittot , Ricardo Neri , Pierre Gondois , Christian Loehle References: <2999205.e9J7NaK4W3@rjwysocki.net> <2317800.iZASKD2KPV@rjwysocki.net> <1bf3df62-0641-459f-99fc-fd511e564b84@samsung.com> From: Dietmar Eggemann Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 12/05/2025 14:53, Rafael J. Wysocki wrote: > On Mon, May 12, 2025 at 8:48 AM Marek Szyprowski > wrote: >> >> On 10.05.2025 13:31, Rafael J. Wysocki wrote: >>> On Sat, May 10, 2025 at 1:49 AM Marek Szyprowski >>> wrote: >>>> On 06.05.2025 22:37, Rafael J. Wysocki wrote: >>>>> From: Rafael J. Wysocki [...] >>>> *** DEADLOCK *** >>> Well, it turns out that trying to acquire policy->rwsem under >>> sched_domains_mutex is a bad idea. It was added to >>> cpufreq_policy_is_good_for_eas() to address a theoretical race, so it >>> can be dropped safely. A theoretical race is better than a real >>> deadlock. >>> >>> Please test the attached patch. >> >> This fixed the observed issue. Thanks! >> >> Reported-by: Marek Szyprowski >> Tested-by: Marek Szyprowski > > Thanks for the confirmation! See this on my Hikey 960 as well. I was wondering why Christian L. and I didn't catch this with RFT v1.0 (*) on i7-13700K. But it looks like that https://web.git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/log/?h=experimental/intel_pstate/eas-take2-extended mentioned in the patch-header of (*) didn't have this line in its commit 9ad047cade6b ("cpufreq/sched: Move cpufreq-specific EAS checks to cpufreq")