From patchwork Mon Nov 14 06:36:09 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Viresh Kumar X-Patchwork-Id: 82010 Delivered-To: patch@linaro.org Received: by 10.140.97.165 with SMTP id m34csp870172qge; Sun, 13 Nov 2016 22:36:16 -0800 (PST) X-Received: by 10.99.131.67 with SMTP id h64mr44411931pge.135.1479105376433; Sun, 13 Nov 2016 22:36:16 -0800 (PST) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 2si9925818pfd.204.2016.11.13.22.36.16; Sun, 13 Nov 2016 22:36:16 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-pm-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.i=@linaro.org; spf=pass (google.com: best guess record for domain of linux-pm-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-pm-owner@vger.kernel.org; dmarc=fail (p=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932268AbcKNGgO (ORCPT + 13 others); Mon, 14 Nov 2016 01:36:14 -0500 Received: from mail-pf0-f175.google.com ([209.85.192.175]:36720 "EHLO mail-pf0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932109AbcKNGgN (ORCPT ); Mon, 14 Nov 2016 01:36:13 -0500 Received: by mail-pf0-f175.google.com with SMTP id 189so27750665pfz.3 for ; Sun, 13 Nov 2016 22:36:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=/PELe+NbJE2J72A8mEyxSs5rTPFb6i1JJJ9lH2jkd2M=; b=AfRHgqr7urLF1QcUZUk1GsXJ9e1yEsKc48ou3XIk1PLq2rWxqqNtuPOdZSomjtd+u2 ZwunN0i03YtP2TKM7KR8ANOrNlVWprMzaqJ9H9Vx881VN9+2r7ps/fIWwQj9wIscr6V9 GrTJNf2UW6M+cxEnVh8ByxQHLKUsRfPlSjEn0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=/PELe+NbJE2J72A8mEyxSs5rTPFb6i1JJJ9lH2jkd2M=; b=XejAqyMc6djW6Pk5+qWX787e7yAg32RKzU30e5Y4Qy/VFVknZoxuvsK9g5cc9+tKFj lfkCqxH7UBZq8LXs8+ir6DSJrCXNIK0cx9oyzdCQyzy+39tY1dzSz8wD2324thtx/9K1 /MUmpulYrJvDf702GWpskgrqERToDSSgycCMRTCgmpGnsX2oi02MC1np+wkLq7lrGPcr bU43zR/LOrSUpuu9KwmPkZhjLMLzOgJl2ub7dRcOU5YeNKtz6waUvMNO94+o6UL5GlTm vQ/fPaik0en196mwr9Vne6jEd8SlH6gdVczSbhvRJ4ePIjyPu5coGVc6BJ/wWjCVP0ii Jnyg== X-Gm-Message-State: ABUngvdO9QezeKi89bXzAHDRRDpW4qdZriHw917Z9KnCSY81iZ+5zK1M8cUDOyKtXlaaAivy X-Received: by 10.99.101.65 with SMTP id z62mr26664668pgb.74.1479105372892; Sun, 13 Nov 2016 22:36:12 -0800 (PST) Received: from localhost ([122.172.89.192]) by smtp.gmail.com with ESMTPSA id m66sm1872413pfm.3.2016.11.13.22.36.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 13 Nov 2016 22:36:11 -0800 (PST) Date: Mon, 14 Nov 2016 12:06:09 +0530 From: Viresh Kumar To: "Rafael J. Wysocki" Cc: Steve Muckle , Saravana Kannan , Rafael Wysocki , Ingo Molnar , Peter Zijlstra , Lists linaro-kernel , Linux PM , Linux Kernel Mailing List , Vincent Guittot , Juri Lelli , Robin Randhawa Subject: Re: [PATCH 2/3] cpufreq: schedutil: move slow path from workqueue to SCHED_FIFO task Message-ID: <20161114063609.GB4178@vireshk-i7> References: <85bf45982709e06f7f42e1b8f8315945e9d9b6d0.1478858983.git.viresh.kumar@linaro.org> <582670FD.7080203@codeaurora.org> <20161113194722.GC29583@graphite.smuckle.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org On 13-11-16, 23:44, Rafael J. Wysocki wrote: > To a minimum, there should be a comment regarding that in the patches. Wanted to get the comment written properly before sending that in the patch. Can you please rectify this based on what you are looking for ? > In any case, the clearing of work_in_progress might still be deferred > by queuing a regular (non-RT) work item to do that from the kthread > work (that will guarantee "hiding" the kthread work from the > governor), but admittedly that would be a sledgehammer of sorts (and > it might defeat the purpose of the whole exercise) ... I agree. -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c index c6bc60078e21..e43f4fd42fb4 100644 --- a/kernel/sched/cpufreq_schedutil.c +++ b/kernel/sched/cpufreq_schedutil.c @@ -313,6 +313,20 @@ static void sugov_irq_work(struct irq_work *irq_work) struct sugov_policy *sg_policy; sg_policy = container_of(irq_work, struct sugov_policy, irq_work); + + /* + * For Real Time and Deadline tasks, schedutil governor shoots the + * frequency to maximum. And special care must be taken to ensure that + * this kthread doesn't result in that. + * + * This is (mostly) guaranteed by the work_in_progress flag. The flag is + * updated only at the end of the sugov_work() and before that schedutil + * rejects all other frequency scaling requests. + * + * Though there is a very rare case where the RT thread yields right + * after the work_in_progress flag is cleared. The effects of that are + * neglected for now. + */ kthread_queue_work(&sg_policy->worker, &sg_policy->work); }