Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp514931ybl; Fri, 31 Jan 2020 03:08:57 -0800 (PST) X-Google-Smtp-Source: APXvYqzuKMCcTUb9+CB+qwqdpf6btQPIfuB5JfBlQHepEhknZXPWKxvAMB1Jq5HN4yNBOGf6jnDY X-Received: by 2002:a9d:5542:: with SMTP id h2mr6686409oti.146.1580468936927; Fri, 31 Jan 2020 03:08:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1580468936; cv=none; d=google.com; s=arc-20160816; b=dsBfjoXcKjm1NYILbU+H+v4Tcbhd6oD/vtCdZ88Ubh8sYk+kvec7iWXc9Rxhftt+Ok MaoiVBzsVeZem50VfuP+GagL1FF93Fh83olBKvmJVt/+rYL05QVs9kLIe0bxp8TI4iq9 YCJh9uqmDQAcETTOhhJb36X2ku6Ybuq0sg1I5NVYVo4FHg+cOXOKEFNx7VdMKSabkk3/ tRAS8izxOa1r78fbKTVsemoD526F99hCp0iFd6IsrPghpVqc30e8XQa9vbfprLUGpHMC 0LtqKtG8UiVDaW2E39phl8l9qZj4FTP+azkGGecj/0wwcle27zuxbMWl5NU6iv+qPAP9 Gaww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :content-language:accept-language:in-reply-to:references:message-id :date:thread-index:thread-topic:subject:cc:to:from; bh=LAKAFESzkwnO3W2vMzkKwS6aGtg8+4CqIsLfHAt6zHM=; b=YtuGSxBQ2MwM7XqmJAGPIo60FGP89+vBfQ+JJp3uGlkvPWHDGpZodtaaKl9gULq7IR YP0DgD7OBxdB/J/rJKkcKknU0tqmvbak+Ju+GLjbsk+aiKPGjZ3BqOwfd3R3rEqaY1GG tD7pFpBmc0R4AFZc7+hWgaTJW1ajavq9CWUW6aW+1imyxDzfuZVuhedu39k/iI283teS 2IAkT5akrUWf/G68HHIdfrIbGVSxyBdnqTu3EDo8aiayZCfFqUh7F21dWUI7kSjm6io5 lKeB2s/seleSE2zAdFBN6KHNh/wRyirqt8ya+0cMT4/fKnaZ6YXZIHEjtxzWTWNFluHG AbPw== 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=aculab.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w20si4225466oic.103.2020.01.31.03.08.44; Fri, 31 Jan 2020 03:08:56 -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=aculab.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728408AbgAaLHq convert rfc822-to-8bit (ORCPT + 99 others); Fri, 31 Jan 2020 06:07:46 -0500 Received: from eu-smtp-delivery-151.mimecast.com ([146.101.78.151]:40266 "EHLO eu-smtp-delivery-151.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728365AbgAaLHp (ORCPT ); Fri, 31 Jan 2020 06:07:45 -0500 Received: from AcuMS.aculab.com (156.67.243.126 [156.67.243.126]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-73-VjcVhdg1N8ihqIuBpg4wFw-1; Fri, 31 Jan 2020 11:07:40 +0000 Received: from AcuMS.Aculab.com (fd9f:af1c:a25b:0:43c:695e:880f:8750) by AcuMS.aculab.com (fd9f:af1c:a25b:0:43c:695e:880f:8750) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 31 Jan 2020 11:07:40 +0000 Received: from AcuMS.Aculab.com ([fe80::43c:695e:880f:8750]) by AcuMS.aculab.com ([fe80::43c:695e:880f:8750%12]) with mapi id 15.00.1347.000; Fri, 31 Jan 2020 11:07:40 +0000 From: David Laight To: "'Rafael J. Wysocki'" , Linux PM CC: Linux ACPI , LKML , Len Brown , Zhang Rui , David Box , "Artem Bityutskiy" , "Rafael J. Wysocki" Subject: RE: [PATCH 2/2] intel_idle: Introduce 'states_off' module parameter Thread-Topic: [PATCH 2/2] intel_idle: Introduce 'states_off' module parameter Thread-Index: AQHV13w6Eg2UWHP5m0aqtl9kDKUdz6gEmmHQ Date: Fri, 31 Jan 2020 11:07:39 +0000 Message-ID: <86fb1cd10e344f76a3e96c4b6c722680@AcuMS.aculab.com> References: <1720216.0Jr2BLnqKp@kreacher> <16995896.bQtfYxEEOs@kreacher> In-Reply-To: <16995896.bQtfYxEEOs@kreacher> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.107] MIME-Version: 1.0 X-MC-Unique: VjcVhdg1N8ihqIuBpg4wFw-1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: aculab.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Rafael J. Wysocki > Sent: 30 January 2020 14:47 > > In certain system configurations it may not be desirable to use some > C-states assumed to be available by intel_idle and the driver needs > to be prevented from using them even before the cpuidle sysfs > interface becomes accessible to user space. Currently, the only way > to achieve that is by setting the 'max_cstate' module parameter to a > value lower than the index of the shallowest of the C-states in > question, but that may be overly intrusive, because it effectively > makes all of the idle states deeper than the 'max_cstate' one go > away (and the C-state to avoid may be in the middle of the range > normally regarded as available). > > To allow that limitation to be overcome, introduce a new module > parameter called 'states_off' to represent a list of idle states to > be disabled by default in the form of a bitmask and update the > documentation to cover it. The problem I see is that there are (at least) 3 different ways of referring to the C-States: 1) The state names, C1, C1E, C3, C7 etc. I'm not sure these are visible outside intel_idle.c. 2) The maximum allowed latency in us. 3) The index into the cpu-dependant tables in intel_idle.c. Boot parameters that set 3 are completely hopeless for normal users. The C-state names might be - but they aren't documented. Unless you know exactly which cpu table is being used the only constraint a user can request is the latency. (I've had the misfortune to read intel_idle.c in the last week. Almost impenetrable TLA ridden uncommented code.) ... > + * The positions of the bits that are set in the two's complement representation > + * of this value are the indices of the idle states to be disabled by default > + * (as reflected by the names of the corresponding idle state directories in > + * sysfs, "state0", "state1" ... "state" ..., where is the index of the > + * given state). What has 'two's complement' got to do with anything? ... > +The value of the ``states_off`` module parameter (0 by default) represents a > +list of idle states to be disabled by default in the form of a bitmask. Namely, > +the positions of the bits that are set in the two's complement representation of > +that value are the indices of idle states to be disabled by default (as > +reflected by the names of the corresponding idle state directories in ``sysfs``, > +:file:`state0`, :file:`state1` ... :file:`state` ..., where ```` is the > +index of the given idle state; see :ref:`idle-states-representation` in > +:doc:`cpuidle`). For example, if ``states_off`` is equal to 3, the driver will > +disable idle states 0 and 1 by default, and if it is equal to 8, idle state 3 > +will be disabled by default and so on (bit positions beyond the maximum idle > +state index are ignored). The idle states disabled this way can be enabled (on > +a per-CPU basis) from user space via ``sysfs``. A few line breaks would make that easier to read. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)