Re: [PATCH 0/8] Move most GPIO documentation to driver-api/gpio/ and ReST

[Linus Walleij]

On Fri, Mar 9, 2018 at 12:40 AM, Jonathan Neuschäfer
 wrote:

> Jonathan Neuschäfer (8):
>   MAINTAINERS: GPIO: Add Documentation/driver-api/gpio/
>   Documentation: driver-api: Move gpio.rst to gpio/index.rst
>   Documentation: gpio: Move introduction to driver-api
>   Documentation: gpio: Move driver documentation to driver-api
>   Documentation: gpio: Move legacy documentation to driver-api
>   Documentation: gpio: Move gpiod_* consumer documentation to driver-api
>   Documentation: gpio: Move GPIO mapping documentation to driver-api
>   Documentation: gpio: Move drivers-on-gpio.txt to driver-api

I applied all 8 patches to devel for v4.17.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 4/6] tty: serial: msm_geni_serial: Add serial driver support for GENI based QUP

[Karthik Ramasubramanian]

On 3/21/2018 11:20 AM, Stephen Boyd wrote:
> Quoting Karthik Ramasubramanian (2018-03-20 15:53:25)
>>
>>
>> On 3/20/2018 9:37 AM, Stephen Boyd wrote:
>>> Quoting Karthikeyan Ramasubramanian (2018-03-14 16:58:49)
 diff --git a/drivers/tty/serial/qcom_geni_serial.c 
 b/drivers/tty/serial/qcom_geni_serial.c
 new file mode 100644
 index 000..1442777
 --- /dev/null
 +++ b/drivers/tty/serial/qcom_geni_serial.c
 @@ -0,0 +1,1158 @@
 +
> 
>>>
>>> Can you also support the OF_EARLYCON_DECLARE method of console writing
>>> so we can get an early printk style debug console?
>> Do you prefer that as part of this patch itself or is it ok if I upload
>> the earlycon support once this gets merged.
> 
> I think this already got merged? So just split it out into another patch
> would be fine. I see the config is already selecting the earlycon
> support so it must be planned.
Yes it is definitely in the plan. Since the serial driver got merged, I
will address the pending comments in this patch series. I will upload
the early console support in another patch.
> 
>>>
>>>
 +
 +static int __maybe_unused qcom_geni_serial_sys_resume_noirq(struct device 
 *dev)
 +{
 +   struct platform_device *pdev = to_platform_device(dev);
 +   struct qcom_geni_serial_port *port = platform_get_drvdata(pdev);
 +   struct uart_port *uport = >uport;
 +
 +   if (console_suspend_enabled && uport->suspended) {
 +   uart_resume_port(uport->private_data, uport);
 +   disable_irq(uport->irq);
>>>
>>> I missed the enable_irq() part. Is this still necessary?
>> Suspending the uart console port invokes the uart port shutdown
>> operation. The shutdown operation disables and frees the concerned IRQ.
>> Resuming the uart console port invokes the uart port startup operation
>> which requests for the IRQ. The request_irq operation auto-enables the
>> IRQ. In addition, resume_noirq implicitly enables the IRQ. This leads to
>> an unbalanced IRQ enable warning.
>>
>> This disable_irq() helps with suppressing that warning.
> 
> That's not obvious so we need a big comment here.
> 
> I thought we would move this to the normal suspend/resume callbacks and
> skip the noirq variants. That would make this disable_irq() unnecessary
> then?
For a non-console UART(eg. 4-wire UART), to reduce the wakeup latency
_noirq variant is used so that the resources can be turned on as soon as
possible. The idea is to use the same suspend and resume operation for
both debug-uart and regular uart. Hence using the _noirq variant.

I will add a detailed comment regarding why we are disabling the IRQ.
> 
> BTW, free_irq() should disable the irq itself, so it looks odd to have a
> disable_irq() followed directly by a free_irq().
I will update to just free_irq.
> 
Regards,
Karthik.
-- 
Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 2/2] cpuset: Add cpuset.sched_load_balance to v2

[Waiman Long]

On 03/22/2018 04:41 AM, Juri Lelli wrote:
> Hi Waiman,
>
> On 21/03/18 12:21, Waiman Long wrote:
>> The sched_load_balance flag is needed to enable CPU isolation similar
>> to what can be done with the "isolcpus" kernel boot parameter.
>>
>> The sched_load_balance flag implies an implicit !cpu_exclusive as
>> it doesn't make sense to have an isolated CPU being load-balanced in
>> another cpuset.
>>
>> For v2, this flag is hierarchical and is inherited by child cpusets. It
>> is not allowed to have this flag turn off in a parent cpuset, but on
>> in a child cpuset.
>>
>> This flag is set by the parent and is not delegatable.
>>
>> Signed-off-by: Waiman Long 
>> ---
>>  Documentation/cgroup-v2.txt | 22 ++
>>  kernel/cgroup/cpuset.c  | 56 
>> +++--
>>  2 files changed, 71 insertions(+), 7 deletions(-)
>>
>> diff --git a/Documentation/cgroup-v2.txt b/Documentation/cgroup-v2.txt
>> index ed8ec66..c970bd7 100644
>> --- a/Documentation/cgroup-v2.txt
>> +++ b/Documentation/cgroup-v2.txt
>> @@ -1514,6 +1514,28 @@ Cpuset Interface Files
>>  it is a subset of "cpuset.mems".  Its value will be affected
>>  by memory nodes hotplug events.
>>  
>> +  cpuset.sched_load_balance
>> +A read-write single value file which exists on non-root cgroups.
>> +The default is "1" (on), and the other possible value is "0"
>> +(off).
>> +
>> +When it is on, tasks within this cpuset will be load-balanced
>> +by the kernel scheduler.  Tasks will be moved from CPUs with
>> +high load to other CPUs within the same cpuset with less load
>> +periodically.
>> +
>> +When it is off, there will be no load balancing among CPUs on
>> +this cgroup.  Tasks will stay in the CPUs they are running on
>> +and will not be moved to other CPUs.
>> +
>> +This flag is hierarchical and is inherited by child cpusets. It
>> +can be turned off only when the CPUs in this cpuset aren't
>> +listed in the cpuset.cpus of other sibling cgroups, and all
>> +the child cpusets, if present, have this flag turned off.
>> +
>> +Once it is off, it cannot be turned back on as long as the
>> +parent cgroup still has this flag in the off state.
>> +
> I'm afraid that this will not work for SCHED_DEADLINE (at least for how
> it is implemented today). As you can see in Documentation [1] the only
> way a user has to perform partitioned/clustered scheduling is to create
> subset of exclusive cpusets and then assign deadline tasks to them. The
> other thing to take into account here is that a root_domain is created
> for each exclusive set and we use such root_domain to keep information
> about admitted bandwidth and speed up load balancing decisions (there is
> a max heap tracking deadlines of active tasks on each root_domain).
> Now, AFAIR distinct root_domain(s) are created when parent group has
> sched_load_balance disabled and cpus_exclusive set (in cgroup v1 that
> is). So, what we normally do is create, say, cpus_exclusive groups for
> the different clusters and then disable sched_load_balance at root level
> (so that each cluster gets its own root_domain). Also,
> sched_load_balance is enabled in children groups (as load balancing
> inside clusters is what we actually needed :).

That looks like an undocumented side effect to me. I would rather see an
explicit control file that enable root_domain and break it free from
cpu_exclusive && !sched_load_balance, e.g. sched_root_domain(?).

> IIUC your proposal this will not be permitted with cgroup v2 because
> sched_load_balance won't be present at root level and children groups
> won't be able to set sched_load_balance back to 1 if that was set to 0
> in some parent. Is that true?

Yes, that is the current plan.

> Look, the way things work today is most probably not perfect (just to
> say one thing, we need to disable load balancing for all classes at root
> level just because DEADLINE wants to set restricted affinities to his
> tasks :/) and we could probably think on how to change how this all
> work. So, let's first see if IIUC what you are proposing (and its
> implications). :)
>
Cgroup v2 is supposed to allow us to have a fresh start to rethink what
is a more sane way of partitioning resources without worrying about
backward compatibility. So I think it is time to design a new way for
deadline tasks to work with cpuset v2.

Cheers,
Longman



--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Documentation: Mention why %p prints ptrval

[Tobin C . Harding]

On Thu, Mar 22, 2018 at 03:53:36PM +1030, Joel Stanley wrote:
> When debugging recent kernels, people will see '(ptrval)' but there
> isn't much information as to what that means. Briefly describe why it's
> there.
> 
> Signed-off-by: Joel Stanley 
> ---
>  Documentation/core-api/printk-formats.rst | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/core-api/printk-formats.rst 
> b/Documentation/core-api/printk-formats.rst
> index 934559b3c130..eb30efdd2e78 100644
> --- a/Documentation/core-api/printk-formats.rst
> +++ b/Documentation/core-api/printk-formats.rst
> @@ -60,8 +60,8 @@ Plain Pointers
>  Pointers printed without a specifier extension (i.e unadorned %p) are
>  hashed to prevent leaking information about the kernel memory layout. This
>  has the added benefit of providing a unique identifier. On 64-bit machines
> -the first 32 bits are zeroed. If you *really* want the address see %px
> -below.
> +the first 32 bits are zeroed. The kernel will print ``(ptrval)`` until it
> +gathers enough entropy. If you *really* want the address see %px below.

Acked-by: Tobin C. Harding 

thanks,
Tobin.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] COPYING: create a new file with points to the Kernel license files

[Matthew Wilcox]

On Thu, Mar 22, 2018 at 06:54:13AM -0300, Mauro Carvalho Chehab wrote:
> +++ b/Documentation/process/license-rules.rst
> @@ -4,15 +4,17 @@ Linux kernel licensing rules
>  
>  
>  The Linux Kernel is provided under the terms of the GNU General Public
> -License version 2 only (GPL-2.0), as published by the Free Software
> -Foundation, and provided in the COPYING file.  This documentation file is
> -not meant to replace the COPYING file, but provides a description of how
> -each source file should be annotated to make the licensing it is governed
> -under clear and unambiguous.
> -
> -The license in the COPYING file applies to the kernel source as a whole,
> -though individual source files can have a different license which is
> -required to be compatible with the GPL-2.0::
> +version 2 only (GPL-2.0), as written at LICENSES/preferred/GPL-2.0,

^^^ you dropped the word 'License' here

Also, I think this should read "as provided in", not "as written at".

> +with an explicit syscall exception described at

s/at/in/

> +LICENSES/exceptions/Linux-syscall-note, as described in the COPYING file.

This phrasing is awkward with "desribed" used twice in the same sentence ...

> +This documentation file is not meant to replace the Kernel's license,
> +but provides a description of how each source file should be annotated
> +to make the licensing it is governed under clear and unambiguous.

I'd rather this said:

This documentation file provides a description of how each source file
should be annotated to make its license clear and unambiguous.

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] Documentation: admin-guide: add kvmconfig, xenconfig and tinyconfig commands

[Martin Kepplinger]

Add kvmconfig, xenconfig and tinyconfig to the list of alternative
configuration commands. Descriptions are directly taken from the Makefile.

Signed-off-by: Martin Kepplinger 
---
 Documentation/admin-guide/README.rst | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/admin-guide/README.rst 
b/Documentation/admin-guide/README.rst
index 155372b3b57f..02caa7efd5ef 100644
--- a/Documentation/admin-guide/README.rst
+++ b/Documentation/admin-guide/README.rst
@@ -218,6 +218,13 @@ Configuring the kernel
  "make localyesconfig" Similar to localmodconfig, except it will convert
all module options to built in (=y) options.
 
+ "make kvmconfig"   Enable additional options for kvm guest kernel support.
+
+ "make xenconfig"   Enable additional options for xen dom0 guest kernel
+support.
+
+ "make tinyconfig"  Configure the tiniest possible kernel.
+
You can find more information on using the Linux kernel config tools
in Documentation/kbuild/kconfig.txt.
 
-- 
2.14.2

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] COPYING: use the new text with points to the license files

[Greg Kroah-Hartman]

On Thu, Mar 22, 2018 at 06:54:14AM -0300, Mauro Carvalho Chehab wrote:
> Now that we have a new COPYING file with points to the
> Linux license files, replace it with the old content.
> 
> This patch does:
>  1 file changed, 0 insertions(+), 0 deletions(-)
>  rename COPYING.new => COPYING (100%)
> 
> Signed-off-by: Mauro Carvalho Chehab 

Reviewed-by: Greg Kroah-Hartman 
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] COPYING: create a new file with points to the Kernel license files

[Greg Kroah-Hartman]

On Thu, Mar 22, 2018 at 06:54:13AM -0300, Mauro Carvalho Chehab wrote:
> With the addition of SPDX patchset, the contents of COPYING file
> is now duplicated at two other files under LICENSE:
>   LICENSES/preferred/GPL-2.0
>   LICENSES/exceptions/Linux-syscall-note
> 
> It is easy to check that the contents of the licence written on
> those files are identical with COPYING using:
> 
>   $ diff -upr COPYING LICENSES/preferred/GPL-2.0
>   $ diff -upr COPYING LICENSES/exceptions/Linux-syscall-note|less
> 
> Also, a new file was added, with describes how SPDX should work at
> the Kernel source files:
>   Documentation/process/license-rules.rst
> 
> Instead fo having it copying the contents of two files, and not
> even mentioning the third one, replace it by a file whose content
> points to the other tree files, preserving the Kernel's license.
> 
> Adjust license-rules.rst accordingly.
> 
> Please notice that this file preserves the Kernel license as
> is, without any changes.
> 
> Signed-off-by: Mauro Carvalho Chehab 

Reviewed-by: Greg Kroah-Hartman 
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] COPYING: use the new text with points to the license files

[Mauro Carvalho Chehab]

Now that we have a new COPYING file with points to the
Linux license files, replace it with the old content.

This patch does:
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename COPYING.new => COPYING (100%)

Signed-off-by: Mauro Carvalho Chehab 
---
 COPYING | 358 ++--
 COPYING.new |  18 ---
 2 files changed, 10 insertions(+), 366 deletions(-)
 delete mode 100644 COPYING.new

diff --git a/COPYING b/COPYING
index ca442d313d86..da4cb28febe6 100644
--- a/COPYING
+++ b/COPYING
@@ -1,356 +1,18 @@
+The Linux Kernel is provided under:
 
-   NOTE! This copyright does *not* cover user programs that use kernel
- services by normal system calls - this is merely considered normal use
- of the kernel, and does *not* fall under the heading of "derived work".
- Also note that the GPL below is copyrighted by the Free Software
- Foundation, but the instance of code that it refers to (the Linux
- kernel) is copyrighted by me and others who actually wrote it.
+   SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note
 
- Also note that the only valid version of the GPL as far as the kernel
- is concerned is _this_ particular version of the license (ie v2, not
- v2.2 or v3.x or whatever), unless explicitly otherwise stated.
+Being under the terms of the GNU General Public License version 2 only,
+according with:
 
-   Linus Torvalds
+   LICENSES/preferred/GPL-2.0
 
-
+With an explicit syscall exception, as stated at:
 
-   GNU GENERAL PUBLIC LICENSE
-  Version 2, June 1991
+   LICENSES/exceptions/Linux-syscall-note
 
- Copyright (C) 1989, 1991 Free Software Foundation, Inc.
-   51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
- Everyone is permitted to copy and distribute verbatim copies
- of this license document, but changing it is not allowed.
+In addition, other licenses may also apply. Please see:
 
-   Preamble
+   Documentation/process/license-rules.rst
 
-  The licenses for most software are designed to take away your
-freedom to share and change it.  By contrast, the GNU General Public
-License is intended to guarantee your freedom to share and change free
-software--to make sure the software is free for all its users.  This
-General Public License applies to most of the Free Software
-Foundation's software and to any other program whose authors commit to
-using it.  (Some other Free Software Foundation software is covered by
-the GNU Library General Public License instead.)  You can apply it to
-your programs, too.
-
-  When we speak of free software, we are referring to freedom, not
-price.  Our General Public Licenses are designed to make sure that you
-have the freedom to distribute copies of free software (and charge for
-this service if you wish), that you receive source code or can get it
-if you want it, that you can change the software or use pieces of it
-in new free programs; and that you know you can do these things.
-
-  To protect your rights, we need to make restrictions that forbid
-anyone to deny you these rights or to ask you to surrender the rights.
-These restrictions translate to certain responsibilities for you if you
-distribute copies of the software, or if you modify it.
-
-  For example, if you distribute copies of such a program, whether
-gratis or for a fee, you must give the recipients all the rights that
-you have.  You must make sure that they, too, receive or can get the
-source code.  And you must show them these terms so they know their
-rights.
-
-  We protect your rights with two steps: (1) copyright the software, and
-(2) offer you this license which gives you legal permission to copy,
-distribute and/or modify the software.
-
-  Also, for each author's protection and ours, we want to make certain
-that everyone understands that there is no warranty for this free
-software.  If the software is modified by someone else and passed on, we
-want its recipients to know that what they have is not the original, so
-that any problems introduced by others will not reflect on the original
-authors' reputations.
-
-  Finally, any free program is threatened constantly by software
-patents.  We wish to avoid the danger that redistributors of a free
-program will individually obtain patent licenses, in effect making the
-program proprietary.  To prevent this, we have made it clear that any
-patent must be licensed for everyone's free use or not licensed at all.
-
-  The precise terms and conditions for copying, distribution and
-modification follow.
-
-   GNU GENERAL PUBLIC LICENSE
-   TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
-
-  0. This License applies to any program or other work which contains
-a notice placed by the copyright holder saying it may be distributed
-under the terms of this General 

[PATCH 0/2] COPYING: create a new file with points to the Kernel license files

[Mauro Carvalho Chehab]

The contents of COPYING file is now duplicated at two other
files under LICENSE:
LICENSES/preferred/GPL-2.0
LICENSES/exceptions/Linux-syscall-note

Also, a new file was added, with describes how SPDX should work at
the Kernel source files:
Documentation/process/license-rules.rst

Instead fo having it copying the contents of two files, and not
even mentioning the third one, replace it by a file whose content
points to the other tree files, preserving the Kernel's license.

Adjust license-rules.rst accordingly.

No license changes.

NOTE



In order to make the diff easier to read, I broke it into two patches.
Feel free to merge both when merging if you want.

Mauro Carvalho Chehab (2):
  COPYING: create a new file with points to the Kernel license files
  COPYING: use the new text with points to the license files

 COPYING | 358 +---
 Documentation/process/license-rules.rst |  20 +-
 2 files changed, 21 insertions(+), 357 deletions(-)

-- 
2.14.3

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] COPYING: create a new file with points to the Kernel license files

[Mauro Carvalho Chehab]

With the addition of SPDX patchset, the contents of COPYING file
is now duplicated at two other files under LICENSE:
LICENSES/preferred/GPL-2.0
LICENSES/exceptions/Linux-syscall-note

It is easy to check that the contents of the licence written on
those files are identical with COPYING using:

$ diff -upr COPYING LICENSES/preferred/GPL-2.0
$ diff -upr COPYING LICENSES/exceptions/Linux-syscall-note|less

Also, a new file was added, with describes how SPDX should work at
the Kernel source files:
Documentation/process/license-rules.rst

Instead fo having it copying the contents of two files, and not
even mentioning the third one, replace it by a file whose content
points to the other tree files, preserving the Kernel's license.

Adjust license-rules.rst accordingly.

Please notice that this file preserves the Kernel license as
is, without any changes.

Signed-off-by: Mauro Carvalho Chehab 
---
 COPYING.new | 18 ++
 Documentation/process/license-rules.rst | 20 +++-
 2 files changed, 29 insertions(+), 9 deletions(-)
 create mode 100644 COPYING.new

diff --git a/COPYING.new b/COPYING.new
new file mode 100644
index ..da4cb28febe6
--- /dev/null
+++ b/COPYING.new
@@ -0,0 +1,18 @@
+The Linux Kernel is provided under:
+
+   SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note
+
+Being under the terms of the GNU General Public License version 2 only,
+according with:
+
+   LICENSES/preferred/GPL-2.0
+
+With an explicit syscall exception, as stated at:
+
+   LICENSES/exceptions/Linux-syscall-note
+
+In addition, other licenses may also apply. Please see:
+
+   Documentation/process/license-rules.rst
+
+for more details.
diff --git a/Documentation/process/license-rules.rst 
b/Documentation/process/license-rules.rst
index 408f77dc6157..bba178e68a0c 100644
--- a/Documentation/process/license-rules.rst
+++ b/Documentation/process/license-rules.rst
@@ -4,15 +4,17 @@ Linux kernel licensing rules
 
 
 The Linux Kernel is provided under the terms of the GNU General Public
-License version 2 only (GPL-2.0), as published by the Free Software
-Foundation, and provided in the COPYING file.  This documentation file is
-not meant to replace the COPYING file, but provides a description of how
-each source file should be annotated to make the licensing it is governed
-under clear and unambiguous.
-
-The license in the COPYING file applies to the kernel source as a whole,
-though individual source files can have a different license which is
-required to be compatible with the GPL-2.0::
+version 2 only (GPL-2.0), as written at LICENSES/preferred/GPL-2.0,
+with an explicit syscall exception described at
+LICENSES/exceptions/Linux-syscall-note, as described in the COPYING file.
+
+This documentation file is not meant to replace the Kernel's license,
+but provides a description of how each source file should be annotated
+to make the licensing it is governed under clear and unambiguous.
+
+The license described in the COPYING file applies to the kernel source
+as a whole, though individual source files can have a different license
+which is required to be compatible with the GPL-2.0::
 
 GPL-1.0+  :  GNU General Public License v1.0 or later
 GPL-2.0+  :  GNU General Public License v2.0 or later
-- 
2.14.3

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] Documentation/CodingStyle: Add an example for braces

[Jani Nikula]

On Wed, 21 Mar 2018, Jonathan Corbet  wrote:
> To head that off, I think I'll apply your first version instead, sorry
> Jani.

No worries.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 2/2] cpuset: Add cpuset.sched_load_balance to v2

[Juri Lelli]

Hi Waiman,

On 21/03/18 12:21, Waiman Long wrote:
> The sched_load_balance flag is needed to enable CPU isolation similar
> to what can be done with the "isolcpus" kernel boot parameter.
> 
> The sched_load_balance flag implies an implicit !cpu_exclusive as
> it doesn't make sense to have an isolated CPU being load-balanced in
> another cpuset.
> 
> For v2, this flag is hierarchical and is inherited by child cpusets. It
> is not allowed to have this flag turn off in a parent cpuset, but on
> in a child cpuset.
> 
> This flag is set by the parent and is not delegatable.
> 
> Signed-off-by: Waiman Long 
> ---
>  Documentation/cgroup-v2.txt | 22 ++
>  kernel/cgroup/cpuset.c  | 56 
> +++--
>  2 files changed, 71 insertions(+), 7 deletions(-)
> 
> diff --git a/Documentation/cgroup-v2.txt b/Documentation/cgroup-v2.txt
> index ed8ec66..c970bd7 100644
> --- a/Documentation/cgroup-v2.txt
> +++ b/Documentation/cgroup-v2.txt
> @@ -1514,6 +1514,28 @@ Cpuset Interface Files
>   it is a subset of "cpuset.mems".  Its value will be affected
>   by memory nodes hotplug events.
>  
> +  cpuset.sched_load_balance
> + A read-write single value file which exists on non-root cgroups.
> + The default is "1" (on), and the other possible value is "0"
> + (off).
> +
> + When it is on, tasks within this cpuset will be load-balanced
> + by the kernel scheduler.  Tasks will be moved from CPUs with
> + high load to other CPUs within the same cpuset with less load
> + periodically.
> +
> + When it is off, there will be no load balancing among CPUs on
> + this cgroup.  Tasks will stay in the CPUs they are running on
> + and will not be moved to other CPUs.
> +
> + This flag is hierarchical and is inherited by child cpusets. It
> + can be turned off only when the CPUs in this cpuset aren't
> + listed in the cpuset.cpus of other sibling cgroups, and all
> + the child cpusets, if present, have this flag turned off.
> +
> + Once it is off, it cannot be turned back on as long as the
> + parent cgroup still has this flag in the off state.
> +

I'm afraid that this will not work for SCHED_DEADLINE (at least for how
it is implemented today). As you can see in Documentation [1] the only
way a user has to perform partitioned/clustered scheduling is to create
subset of exclusive cpusets and then assign deadline tasks to them. The
other thing to take into account here is that a root_domain is created
for each exclusive set and we use such root_domain to keep information
about admitted bandwidth and speed up load balancing decisions (there is
a max heap tracking deadlines of active tasks on each root_domain).

Now, AFAIR distinct root_domain(s) are created when parent group has
sched_load_balance disabled and cpus_exclusive set (in cgroup v1 that
is). So, what we normally do is create, say, cpus_exclusive groups for
the different clusters and then disable sched_load_balance at root level
(so that each cluster gets its own root_domain). Also,
sched_load_balance is enabled in children groups (as load balancing
inside clusters is what we actually needed :).

IIUC your proposal this will not be permitted with cgroup v2 because
sched_load_balance won't be present at root level and children groups
won't be able to set sched_load_balance back to 1 if that was set to 0
in some parent. Is that true?

Look, the way things work today is most probably not perfect (just to
say one thing, we need to disable load balancing for all classes at root
level just because DEADLINE wants to set restricted affinities to his
tasks :/) and we could probably think on how to change how this all
work. So, let's first see if IIUC what you are proposing (and its
implications). :)

Best,

- Juri

[1] 
https://elixir.bootlin.com/linux/v4.16-rc6/source/Documentation/scheduler/sched-deadline.txt#L640
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html