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 X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EF95AC433E2 for ; Thu, 4 Jun 2020 07:12:12 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B62A3206DC for ; Thu, 4 Jun 2020 07:12:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B62A3206DC Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 615F46E288; Thu, 4 Jun 2020 07:11:45 +0000 (UTC) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by gabe.freedesktop.org (Postfix) with ESMTP id 3A3BE89BDB for ; Wed, 3 Jun 2020 15:26:03 +0000 (UTC) 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 85D2A55D; Wed, 3 Jun 2020 08:26:02 -0700 (PDT) Received: from [10.37.12.87] (unknown [10.37.12.87]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 2A4FB3F52E; Wed, 3 Jun 2020 08:25:51 -0700 (PDT) Subject: Re: [PATCH v8 4/8] PM / EM: add support for other devices than CPUs in Energy Model To: "Rafael J. Wysocki" References: <20200527095854.21714-1-lukasz.luba@arm.com> <20200527095854.21714-5-lukasz.luba@arm.com> <7201e161-6952-6e28-4036-bd0f0353ec30@arm.com> From: Lukasz Luba Message-ID: Date: Wed, 3 Jun 2020 16:25:50 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-Mailman-Approved-At: Thu, 04 Jun 2020 07:11:42 +0000 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Nishanth Menon , Juri Lelli , Peter Zijlstra , Viresh Kumar , Liviu Dudau , dri-devel , Bjorn Andersson , Benjamin Segall , alyssa.rosenzweig@collabora.com, Matthias Kaehlcke , Amit Kucheria , Lorenzo Pieralisi , Vincent Guittot , Kevin Hilman , Andy Gross , Daniel Lezcano , steven.price@arm.com, Chanwoo Choi , Ingo Molnar , dl-linux-imx , "Zhang, Rui" , Mel Gorman , orjan.eide@arm.com, Linux PM , linux-arm-msm , Sascha Hauer , Steven Rostedt , "moderated list:ARM/Mediatek SoC..." , Matthias Brugger , Linux OMAP Mailing List , Dietmar Eggemann , Linux ARM , David Airlie , Tomeu Vizoso , Quentin Perret , Stephen Boyd , Randy Dunlap , "Rafael J. Wysocki" , Linux Kernel Mailing List , Bartlomiej Zolnierkiewicz , Sascha Hauer , Sudeep Holla , patrick.bellasi@matbug.net, Shawn Guo Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On 6/3/20 4:13 PM, Rafael J. Wysocki wrote: > On Tue, Jun 2, 2020 at 1:31 PM Lukasz Luba wrote: >> >> Hi Daniel, >> >> On 6/1/20 10:44 PM, Daniel Lezcano wrote: >>> On 27/05/2020 11:58, Lukasz Luba wrote: >>>> Add support for other devices than CPUs. The registration function >>>> does not require a valid cpumask pointer and is ready to handle new >>>> devices. Some of the internal structures has been reorganized in order to >>>> keep consistent view (like removing per_cpu pd pointers). >>>> >>>> Signed-off-by: Lukasz Luba >>>> --- >>> >>> [ ... ] >>> >>>> } >>>> EXPORT_SYMBOL_GPL(em_register_perf_domain); >>>> + >>>> +/** >>>> + * em_dev_unregister_perf_domain() - Unregister Energy Model (EM) for a device >>>> + * @dev : Device for which the EM is registered >>>> + * >>>> + * Try to unregister the EM for the specified device (but not a CPU). >>>> + */ >>>> +void em_dev_unregister_perf_domain(struct device *dev) >>>> +{ >>>> + if (IS_ERR_OR_NULL(dev) || !dev->em_pd) >>>> + return; >>>> + >>>> + if (_is_cpu_device(dev)) >>>> + return; >>>> + >>>> + mutex_lock(&em_pd_mutex); >>> >>> Is the mutex really needed? >> >> I just wanted to align this unregister code with register. Since there >> is debugfs dir lookup and the device's EM existence checks I thought it >> wouldn't harm just to lock for a while and make sure the registration >> path is not used. These two paths shouldn't affect each other, but with >> modules loading/unloading I wanted to play safe. >> >> I can change it maybe to just dmb() and the end of the function if it's >> a big performance problem in this unloading path. What do you think? > > I would rather leave the mutex locking as is. > > However, the question to ask is what exactly may go wrong without that > locking in place? Is there any specific race condition that you are > concerned about? > I tried to test this with module loading & unloading with panfrost driver and CPU hotplug (which should bail out quickly) and was OK. I don't see any particular race. I don't too much about the debugfs code, though. That's why I tried to protect from some scripts/services which try to re-load the driver. Apart from that, maybe just this dev->em = NULL to be populated to all CPUs, which mutex_unlock synchronizes for free here. Regards, Lukasz _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel