Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp563110ybl; Fri, 31 Jan 2020 04:05:05 -0800 (PST) X-Google-Smtp-Source: APXvYqzi+pLhFbUq3KKHr1DHmR0u+l851vn6AzSABW3FM/d3CEIKaQN4d6tSS2p/VJJ6CToEMArz X-Received: by 2002:a9d:811:: with SMTP id 17mr7558784oty.369.1580472305311; Fri, 31 Jan 2020 04:05:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1580472305; cv=none; d=google.com; s=arc-20160816; b=GHE11axdWTZCSPvaKc+io53EJKVDmBY/FUorW8NBt91zjsi5h48FhhWufbm0Q/dU5b /YxCo0GYuXwbPgEptDsIeTJzJ++twADSRdXk5Y9tc2S5UZvsxU0tQc9KH+Psdz6HO6IV 6NRt2LLarsU6Vzoi+0bhkpvYvm7WqK7jiy2qwhWt9M+iWOPrDrGwvYstFPinSsd/gMRY A0IjvFVLveNycgIvk2BBHIeNslBZzJqhT2OHb96EbwGdn595FxO7e7tBEWepKNT8s05d e7gKRtnyWoi34lTop4n2xb46ql/3gLWuSBHF4+6Mumr6udeWvmu+hUzVz9D1LcXGMvEV hG2w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version; bh=HqpET/J/MD20LaDgPuTRS5n8V9jD3XdrrukQnBqfyM4=; b=jAsBD5s9MaEaiMmWGWYNaA9rGplE7m4/MvRaY8VDeJJqV7CtNiKHRetkSnfK/W9NOs c4QghSyRHqx+e3nSP6yRGFIaV10Vo7mHwUk3vPO8E1P5DQql5BkEIacVBGmXuU4u1J8O zGiq/6svbIY+JP7pVbdoXy1MrbxQDX9BRgXr9/Nktt6pYfO6qinRCRYST1JC0Y0sfo72 B2YimziwJAO6EsiEYnCyq/ToyS6n2+uwVTWSCDiHWHxs2VQCDBjeuaqrp3Hm7mmXYzJr VpD7OmcUm8Q9BNHCHB4Vq2iDjVG7KxR7OzlVTFt8Bl7QDIBoQwTxi5TM8ugvUqTdlSu5 6eOA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g24si4761012otj.59.2020.01.31.04.04.49; Fri, 31 Jan 2020 04:05:05 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728526AbgAaMDw (ORCPT + 99 others); Fri, 31 Jan 2020 07:03:52 -0500 Received: from mail-ot1-f66.google.com ([209.85.210.66]:40077 "EHLO mail-ot1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728408AbgAaMDw (ORCPT ); Fri, 31 Jan 2020 07:03:52 -0500 Received: by mail-ot1-f66.google.com with SMTP id i6so6311381otr.7; Fri, 31 Jan 2020 04:03:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HqpET/J/MD20LaDgPuTRS5n8V9jD3XdrrukQnBqfyM4=; b=AP9QRkV/MnARxZfM7GWa1FizijRkVAZFh4wOJGFKRVbNueicbp8nrJj2Jua1rCQKjV lb95oCe2ZL3Jx9RRaF+prjgyrMUfi48MK5s8Bnt7ywnYhi3shnN6kcdgcrqmpV2IQCTh C8klCRPn55wgD8pkqyPg6Bc5FLho14rphHl4Yl7Q+iXLnxWLlJd5XWR/Q8j0oTIzD8Yv xT1vU4bOyuIl/zkWATUJr7708e4J10PeRq/8qgbZ4EEhcS85g7as0roRrHx1Z68uTVtt UsFGjPLEeA8NfqUCgqLT33/BsCHP6F8zNmadsNeUR0U73+CaCkeOnyowAM9XwKkfK0iz /ZWQ== X-Gm-Message-State: APjAAAVQiSU83xReG1vYqEPWqmj7Ajv10pwlLunkqSKoDYpGzSa6Szon j/uOrewEC3aMG7y7x3iGaFLMJlBttyQ2ifyrRAs= X-Received: by 2002:a05:6830:4b9:: with SMTP id l25mr7434450otd.266.1580472231259; Fri, 31 Jan 2020 04:03:51 -0800 (PST) MIME-Version: 1.0 References: <1720216.0Jr2BLnqKp@kreacher> <16995896.bQtfYxEEOs@kreacher> <86fb1cd10e344f76a3e96c4b6c722680@AcuMS.aculab.com> <28a92577c83276baf355dc8de272a79dc854025a.camel@linux.intel.com> <6cf71f6964c6433abeaf445847c97611@AcuMS.aculab.com> In-Reply-To: <6cf71f6964c6433abeaf445847c97611@AcuMS.aculab.com> From: "Rafael J. Wysocki" Date: Fri, 31 Jan 2020 13:03:40 +0100 Message-ID: Subject: Re: [PATCH 2/2] intel_idle: Introduce 'states_off' module parameter To: David Laight Cc: "artem.bityutskiy@linux.intel.com" , "Rafael J. Wysocki" , Linux PM , Linux ACPI , LKML , Len Brown , Zhang Rui , David Box , "Rafael J. Wysocki" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 31, 2020 at 12:54 PM David Laight wrote: > > From: Artem Bityutskiy > > > Sent: 31 January 2020 11:24 > > On Fri, 2020-01-31 at 11:07 +0000, David Laight wrote: > > > Unless you know exactly which cpu table is being used the > > > only constraint a user can request is the latency. > > > > Hi David, > > > > in all my use-cases I always know what is the CPU I am dealing with and > > what are the C-states. Simply because in my view they are always CPU- > > dependent in terms of what they do and how are they named. > > > > What you say sounds to me like you would want to disable some C-states > > without knowing anything (or much) about the CPU you are dealing with > > and the C-state names. > > > > If so, could you please share examples of such use-cases? > > Dunno, but clearly you want to disable (say) C3 while leaving C6 > enabled. > > I was trying to find why it was taking 600+us for a RT process > to get rescheduled when it had only been sleeping for a few us. > > I found where it was sleeping, but that didn't help at all. > Someone pointed me at a 'random' pdf that referred to /dev/cpu_dma_latency. > Setting that to a small value (eg 20) helps no end. > But there are no references in the code or man pages to that. There is a piece of kernel documentation regarding it, however: https://www.kernel.org/doc/html/latest/admin-guide/pm/cpuidle.html#cpu-pm-qos