On 05/25/2018 05:40 AM, Patrick Bellasi wrote:
> On 24-May 11:22, Waiman Long wrote:
>> On 05/24/2018 11:16 AM, Juri Lelli wrote:
>>> On 24/05/18 11:09, Waiman Long wrote:
>>>> On 05/24/2018 10:36 AM, Juri Lelli wrote:
>>>
On 05/24/2018 11:43 AM, Peter Zijlstra wrote:
> On Thu, May 17, 2018 at 04:55:42PM -0400, 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. Its value
>> can
On 05/24/2018 11:41 AM, Peter Zijlstra wrote:
> On Thu, May 17, 2018 at 04:55:41PM -0400, Waiman Long wrote:
>> A new cpuset.sched.domain boolean flag is added to cpuset v2. This new
>> flag indicates that the CPUs in the current cpuset should be treated
>> as a separ
On 05/24/2018 11:16 AM, Juri Lelli wrote:
> On 24/05/18 11:09, Waiman Long wrote:
>> On 05/24/2018 10:36 AM, Juri Lelli wrote:
>>> On 17/05/18 16:55, Waiman Long wrote:
>>>
>>> [...]
>>>
>>>> + A parent cgroup cannot distribute all its C
On 05/23/2018 01:34 PM, Patrick Bellasi wrote:
> Hi Waiman,
>
> On 17-May 16:55, Waiman Long wrote:
>
> [...]
>
>> @@ -672,13 +672,14 @@ static int generate_sched_domains(cpumask_var_t
>> **domains,
>> int ndoms = 0; /* number of sched do
On 05/22/2018 08:57 AM, Juri Lelli wrote:
> Hi,
>
> On 17/05/18 16:55, Waiman Long wrote:
>
> [...]
>
>> /**
>> + * update_isolated_cpumask - update the isolated_cpus mask of parent cpuset
>> + * @cpuset: The cpuset that requests CPU isolation
>&
On 05/21/2018 11:09 AM, Patrick Bellasi wrote:
> On 21-May 09:55, Waiman Long wrote:
>
>> Changing cpuset.cpus will require searching for the all the tasks in
>> the cpuset and change its cpu mask.
> ... I'm wondering if that has to be the case. In principle there can
>
anwhile I have
> some (hopefully not too much dummy) questions below.
>
> On 17-May 16:55, Waiman Long wrote:
>> Given the fact that thread mode had been merged into 4.14, it is now
>> time to enable cpuset to be used in the default hierarchy (cgroup v2)
>> as it is c
its parent is either
root or a scheduling domain itself with non-empty cpu list. The state
of this flag cannot be changed if the cpuset has children.
Signed-off-by: Waiman Long <long...@redhat.com>
---
Documentation/cgroup-v2.txt | 22
kernel/cgroup/cpuset.c
d from its parent.
This flag is set by the parent and is not delegatable.
Signed-off-by: Waiman Long <long...@redhat.com>
---
Documentation/cgroup-v2.txt | 24
kernel/cgroup/cpuset.c | 53 +
2 files changed, 73 insertions
The generate_sched_domains() function and the hotplug code are modified
to make them use the newly introduced isolated_cpus mask for schedule
domains generation.
Signed-off-by: Waiman Long <long...@redhat.com>
---
kernel/cgroup/cpuset.c | 33 +
1 file chang
features, if desired, to
memory controller or may be to the cpu controller instead of staying
with cpuset.
Signed-off-by: Waiman Long <long...@redhat.com>
---
Documentation/cgroup-v2.txt | 90 ++---
kernel/cgroup/cpuset.c | 48 +
ges are being made.
Signed-off-by: Waiman Long <long...@redhat.com>
---
kernel/cgroup/cpuset.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
index fb8aa82b..8f586e8 100644
--- a/kernel/cgroup/cpuset.c
+++ b/kernel/cgroup/cpuset.
eduling domain genaration code to work with
the new scheduling domain feature.
Patch 5 exposes cpus.effective and mems.effective to the root cgroup as
enabling child scheduling domains will take CPUs away from the root cgroup.
So it will be nice to monitor what CPUs are left there.
Patch 6 enables th
sed in
the v2 cgroup root.
For consistency, the "cpuset.mems.effective" control file is exposed
as well.
Signed-off-by: Waiman Long <long...@redhat.com>
---
Documentation/cgroup-v2.txt | 4 ++--
kernel/cgroup/cpuset.c | 2 --
2 files changed, 2 insertions(+), 4 deletions(-)
On 05/02/2018 10:08 AM, Peter Zijlstra wrote:
> On Thu, Apr 19, 2018 at 09:47:02AM -0400, Waiman Long wrote:
>> diff --git a/Documentation/cgroup-v2.txt b/Documentation/cgroup-v2.txt
>> index c970bd7..8d89dc2 100644
>> --- a/Documentation/cgroup-v2.txt
>> +++ b/
On 05/07/2018 07:17 PM, Luis R. Rodriguez wrote:
> On Mon, May 07, 2018 at 04:59:11PM -0400, Waiman Long wrote:
>> diff --git a/ipc/ipc_sysctl.c b/ipc/ipc_sysctl.c
>> index 49f9bf4..d62335f 100644
>> --- a/ipc/ipc_sysctl.c
>> +++ b/ipc/ipc_sysctl.c
>&g
On 05/07/2018 06:39 PM, Luis R. Rodriguez wrote:
> On Mon, May 07, 2018 at 04:59:09PM -0400, Waiman Long wrote:
>> A user can write arbitrary integer values to msgmni and shmmni sysctl
>> parameters without getting error, but the actual limit is really
>> IPCMNI (32k). T
that it is limited to the [0, IPCMNI] range. An error will be returned
if this is not the case.
Signed-off-by: Waiman Long <long...@redhat.com>
---
ipc/ipc_sysctl.c | 23 ++-
ipc/util.h | 9 +
2 files changed, 31 insertions(+), 1 deletion(-)
diff --git a/ipc/ipc_sysctl.c
will become aware if they set a value outside of the acceptable range.
Signed-off-by: Waiman Long <long...@redhat.com>
---
ipc/ipc_sysctl.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/ipc/ipc_sysctl.c b/ipc/ipc_sysctl.c
index 8ad93c2..f87cb29 100644
---
to extend the IPCMNI value to 2M. This is a 64X increase which
hopefully is big enough for them.
This new option does have the side effect of reducing the maximum
number of unique sequence numbers from 64k down to 1k. So it is
a trade-off.
Signed-off-by: Waiman Long <long...@redhat.com>
---
Doc
done in the extended IPCMNI mode,
Signed-off-by: Waiman Long <long...@redhat.com>
---
include/linux/ipc_namespace.h | 1 +
ipc/ipc_sysctl.c | 2 ++
ipc/util.c| 29 ++---
ipc/util.h| 2 ++
4 files changed, 27 inse
_extend" to increase the IPCMNI limit from 32k to 2M if the users
really want the extended value.
Waiman Long (4):
ipc: IPCMNI limit check for msgmni and shmmni
ipc: IPCMNI limit check for semmni
ipc: Allow boot time extension of IPCMNI from 32k to 2M
ipc: Conserve sequence numbers in
On 05/02/2018 11:06 AM, Eric W. Biederman wrote:
>
>>> and or users that may or may not exist. If you can find something that
>>> will care sure. We need to avoid breaking userspace and causing
>>> regressions. However as this stands it looks you are making maintenance
>>> of the kernel more
On 05/02/2018 09:42 AM, Peter Zijlstra wrote:
> On Wed, May 02, 2018 at 09:29:54AM -0400, Waiman Long wrote:
>> On 05/02/2018 06:24 AM, Peter Zijlstra wrote:
>>> On Thu, Apr 19, 2018 at 09:47:01AM -0400, Waiman Long wrote:
>>>> + cpuset.sched_load_balance
>>
On 05/02/2018 06:24 AM, Peter Zijlstra wrote:
> On Thu, Apr 19, 2018 at 09:47:01AM -0400, Waiman Long wrote:
>> + cpuset.sched_load_balance
>> +A read-write single value file which exists on non-root cgroups.
> Uhhm.. it should very much exist in the root group too. Othe
On 05/01/2018 10:18 PM, Eric W. Biederman wrote:
>
>> The sysctl parameters msgmni, shmmni and semmni have an inherent limit
>> of IPC_MNI (32k). However, users may not be aware of that because they
>> can write a value much higher than that without getting any error or
>> notification. Reading
On 05/01/2018 04:58 PM, Tejun Heo wrote:
> Hello,
>
> On Tue, May 01, 2018 at 04:33:45PM -0400, Waiman Long wrote:
>> I think that will work too. We currently don't have a flag to make a
>> file visible on first-level children only, but it shouldn't be hard to
>> make
On 05/01/2018 03:51 PM, Tejun Heo wrote:
> Hello, Waiman.
>
> Sorry about the delay.
>
> On Thu, Apr 19, 2018 at 09:47:03AM -0400, Waiman Long wrote:
>> With the addition of "cpuset.cpus.isolated", it makes sense to add the
>> restriction that load balanci
On 04/30/2018 06:40 PM, Kees Cook wrote:
> I like this series overall, thanks! No objections from me. One thing I
> noted, though:
>
> On Fri, Apr 27, 2018 at 2:00 PM, Waiman Long <long...@redhat.com> wrote:
>> if (param-&
buffer when a clamped sysctl parameter
receives an out of range value.
The pr_warn_ratelimited() macro is used to limit the number of warning
messages that can be printed within a given period of time.
Signed-off-by: Waiman Long <long...@redhat.com>
---
kernel/sysctl.
or unsigned
flags.
The separation of signed and unsigned flags helps to provide more
comprehensive checking than it would have been if there is only one
flag available.
Signed-off-by: Waiman Long <long...@redhat.com>
---
fs/proc/proc_sysctl.
or checking the kernel ring buffer for warning.
Signed-off-by: Waiman Long <long...@redhat.com>
---
ipc/ipc_sysctl.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/ipc/ipc_sysctl.c b/ipc/ipc_sysctl.c
index 8ad93c2..d71f949 100644
--- a/ipc/ipc_sysctl.c
+++
us to
perform more comprehensive checking in a later patch.
Extra braces are also used in this patch to make a latter patch easier
to read.
Signed-off-by: Waiman Long <long...@redhat.com>
---
include/linux/sysctl.h | 32 ++
kernel/sysctl.c
minimum clamping ... ok
Checking range maximum clamping ... ok
Signed-off-by: Waiman Long <long...@redhat.com>
---
lib/test_sysctl.c| 29 ++
tools/testing/selftests/sysctl/sysctl.sh | 52
2 files changed, 81 inse
that it is clamped to the [0, IPCMNI] range and prints
a warning message once when an out-of-range value is being written.
This does require duplicating some of the code in the _minmax handlers.
Signed-off-by: Waiman Long <long...@redhat.com>
---
ipc/ipc_sysctl.c | 12 +++-
ipc/sem.c
to extend the IPCMNI value to 2M. This is a 64X increase which
hopefully is big enough for them.
This new option does have the side effect of reducing the maximum
number of unique sequence numbers from 64k down to 1k. So it is
a trade-off.
Signed-off-by: Waiman Long <long...@redhat.com>
---
Doc
done in the extended IPCMNI mode,
Signed-off-by: Waiman Long <long...@redhat.com>
---
include/linux/ipc_namespace.h | 1 +
ipc/ipc_sysctl.c | 2 ++
ipc/util.c| 29 ++---
ipc/util.h| 1 +
4 files changed, 26 inse
hange in behavior unless they explictly opt in to enable the extended
mode. I could open up the whole positive integer space in this case
like what Eric did, but that will make the code more complex. So I
just extend IPCMNI to 2M in this case and keep similar ID generation
logic.
Waiman Long
On 04/20/2018 04:23 AM, Mike Galbraith wrote:
> On Thu, 2018-04-19 at 09:46 -0400, Waiman Long wrote:
>> v7:
>> - Add a root-only cpuset.cpus.isolated control file for CPU isolation.
>> - Enforce that load_balancing can only be turned off on cpusets with
>>
On 04/23/2018 09:57 AM, Juri Lelli wrote:
> On 23/04/18 15:07, Juri Lelli wrote:
>> Hi Waiman,
>>
>> On 19/04/18 09:46, Waiman Long wrote:
>>> v7:
>>> - Add a root-only cpuset.cpus.isolated control file for CPU isolation.
>>> - Enforce that
/proc/stat and be duplicated in
/proc/stat_irqs. Applications that need to look up individual irq counts
will now have to look into /proc/stat_irqs instead of /proc/stat.
v2: Update Documentation/filesystems/proc.txt accordingly.
Signed-off-by: Waiman Long <long...@redhat.com>
---
Documenta
solated".
In other words, all the CPUs that need to be isolated or in separate
root domains have to be put into the "cpuset.cpus.isolated" first. Then
child cpusets can be created to partition those isolated CPUs into
either separate root domains with "sched_load_balance" on or
The generate_sched_domains() function and the hotplug code are modified
to make them use the newly introduced isolated_cpus mask for schedule
domains generation.
Signed-off-by: Waiman Long <long...@redhat.com>
---
kernel/cgroup/cpuset.c | 35 +--
1 file c
t.
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 <long...@redhat.com>
---
Documentation/cg
features, if desired, to
memory controller or may be to the cpu controller instead of staying
with cpuset.
Signed-off-by: Waiman Long <long...@redhat.com>
---
Documentation/cgroup-v2.txt | 90 ++---
kernel/cgroup/cpuset.c | 48 +
state are in any of the child cpusets.
Signed-off-by: Waiman Long <long...@redhat.com>
---
Documentation/cgroup-v2.txt | 25 ++
kernel/cgroup/cpuset.c | 119 +++-
2 files changed, 143 insertions(+), 1 deletion(-)
diff --git a/Documen
With the addition of "cpuset.cpus.isolated", it makes sense to add the
restriction that load balancing can only be turned off if the CPUs in
the isolated cpuset are subset of "cpuset.cpus.isolated".
Signed-off-by: Waiman Long <long...@redhat.com>
---
Docume
On 03/29/2018 02:15 PM, Luis R. Rodriguez wrote:
> On Mon, Mar 19, 2018 at 11:39:19AM -0400, Waiman Long wrote:
>> On 03/16/2018 09:10 PM, Luis R. Rodriguez wrote:
>>> On Fri, Mar 16, 2018 at 02:13:42PM -0400, Waiman Long wrote:
>>>> When the CTL_FLAGS_CLAMP_RANG
On 03/27/2018 10:02 AM, Tejun Heo wrote:
> Hello,
>
> On Mon, Mar 26, 2018 at 04:28:49PM -0400, Waiman Long wrote:
>> Maybe we can have a different root level flag, say,
>> sched_partition_domain that is equivalent to !sched_load_balnace.
>> However, I am still no
On 03/26/2018 08:47 AM, Juri Lelli wrote:
> On 23/03/18 14:44, Waiman Long wrote:
>> On 03/23/2018 03:59 AM, Juri Lelli wrote:
> [...]
>
>>> OK, thanks for confirming. Can you tell again however why do you think
>>> we need to remove sched_load_balance from root
On 03/23/2018 03:59 AM, Juri Lelli wrote:
> On 22/03/18 17:50, Waiman Long wrote:
>> On 03/22/2018 04:41 AM, Juri Lelli wrote:
>>> On 21/03/18 12:21, Waiman Long wrote:
> [...]
>
>>>> + cpuset.sched_load_balance
>>>> + A read-write si
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
p v2 with cpus, mems and their
effective counterparts.
Patch 2 adds sched_load_balance whose behavior changes in v2 to become
hierarchical and includes an implicit !cpu_exclusive.
Waiman Long (2):
cpuset: Enable cpuset controller in default hierarchy
cpuset: Add cpuset.sched_load_balance to v2
Doc
t.
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 <long...@redhat.com>
---
Documentation/cg
features, if desired, to
memory controller or may be to the cpu controller instead of staying
with cpuset.
Signed-off-by: Waiman Long <long...@redhat.com>
---
Documentation/cgroup-v2.txt | 90 ++---
kernel/cgroup/cpuset.c | 48 +
On 03/20/2018 05:14 PM, Tejun Heo wrote:
> Hello,
>
> On Tue, Mar 20, 2018 at 04:53:37PM -0400, Waiman Long wrote:
>> ASAIK for v2, when cpuset.cpus is empty, cpuset.effective_cpus will show
>> all the cpus available from the parent. It is a different behavior from
>&
On 03/20/2018 04:10 PM, Tejun Heo wrote:
> Hello, Waiman.
>
> On Tue, Mar 20, 2018 at 09:51:20AM -0400, Waiman Long wrote:
>>>> + It lists the onlined CPUs that are actually allowed to be
>>>> + used by tasks within the current cgroup. It is a subset of
On 03/20/2018 04:22 PM, Tejun Heo wrote:
> Hello, Waiman.
>
> On Tue, Mar 20, 2018 at 04:12:25PM -0400, Waiman Long wrote:
>> After some thought, I am planning to impose the following additional
>> constraints on how sched_load_balance works in v2.
>>
>> 1
On 03/19/2018 12:33 PM, Waiman Long wrote:
> On 03/19/2018 12:26 PM, Tejun Heo wrote:
>> Hello, Waiman.
>>
>> On Thu, Mar 15, 2018 at 05:20:42PM -0400, Waiman Long wrote:
>>> + The currently supported flag is:
>>> +
>>> + sched
On 03/19/2018 11:59 AM, Tejun Heo wrote:
> Hello, Waiman.
>
> This looks great. A couple nitpicks below.
>
>> + 5-3. Cpuset
>> + 5.3-1. Cpuset Interface Files
> Can we put cpuset below pid? It feels weird to break up cpu, memory
> and io as they represent the three major resources and
On 03/19/2018 04:49 PM, Mike Galbraith wrote:
> On Mon, 2018-03-19 at 08:34 -0700, Tejun Heo wrote:
>> Hello, Mike.
>>
>> On Thu, Mar 15, 2018 at 03:49:01AM +0100, Mike Galbraith wrote:
>>> Under the hood v2 details are entirely up to you. My input ends at
>>> please don't leave dynamic
On 03/19/2018 12:26 PM, Tejun Heo wrote:
> Hello, Waiman.
>
> On Thu, Mar 15, 2018 at 05:20:42PM -0400, Waiman Long wrote:
>> +The currently supported flag is:
>> +
>> + sched_load_balance
>> +When it is not set, there will be no load bal
On 03/16/2018 09:10 PM, Luis R. Rodriguez wrote:
> On Fri, Mar 16, 2018 at 02:13:42PM -0400, Waiman Long wrote:
>> When the CTL_FLAGS_CLAMP_RANGE flag is set in the ctl_table
>> entry, any update from the userspace will be clamped to the given
>> range wi
On 03/16/2018 08:54 PM, Luis R. Rodriguez wrote:
> On Fri, Mar 16, 2018 at 02:13:43PM -0400, Waiman Long wrote:
>> Checking code is added to provide the following additional
>> ctl_table.flags checks:
>>
>> 1) No unknown flag is allowed.
>> 2) Minimum of a range
that it is clamped to the [0, IPCMNI] range and prints
a warning message once when an out-of-range value is being written.
This does require duplicating some of the code in the _minmax handlers.
Signed-off-by: Waiman Long <long...@redhat.com>
---
ipc/ipc_sysctl.c | 12 +++-
ipc/sem.c
.
Signed-off-by: Waiman Long <long...@redhat.com>
---
ipc/ipc_sysctl.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/ipc/ipc_sysctl.c b/ipc/ipc_sysctl.c
index 8ad93c2..088721e 100644
--- a/ipc/ipc_sysctl.c
+++ b/ipc/ipc_sysctl.c
@@ -99,6 +99,7 @@ stat
and error messages
to be printed into the dmesg log, though.
A new test is also added to the sysctl.sh to look for those failure
messages in the dmesg log to see if anything unexpeced happens.
Signed-off-by: Waiman Long <long...@redhat.com>
---
lib/test_sysctl.c
to extend the IPCMNI value to 2M. This is a 64X increase which
hopefully is big enough for them.
This new option does have the side effect of reducing the maximum
number of unique sequence numbers from 64k down to 1k. So it is
a trade-off.
Signed-off-by: Waiman Long <long...@redhat.com>
---
Doc
done in the extended IPCMNI mode,
Signed-off-by: Waiman Long <long...@redhat.com>
---
include/linux/ipc_namespace.h | 1 +
ipc/ipc_sysctl.c | 2 ++
ipc/util.c| 29 ++---
ipc/util.h| 1 +
4 files changed, 26 inse
minimum clamping ... ok
Checking range maximum clamping ... ok
Signed-off-by: Waiman Long <long...@redhat.com>
---
lib/test_sysctl.c| 29 ++
tools/testing/selftests/sysctl/sysctl.sh | 52
2 files changed, 81 inse
-off-by: Waiman Long <long...@redhat.com>
---
fs/proc/proc_sysctl.c | 62 ++
include/linux/sysctl.h | 16 +++--
2 files changed, 76 insertions(+), 2 deletions(-)
diff --git a/fs/proc/proc_sysctl.c b/fs/proc/proc_sysctl.c
index 493c97
buffer when a clamped sysctl parameter
receives an out of range value.
The pr_warn_ratelimited() macro is used to limit the number of warning
messages that can be printed within a given period of time.
Signed-off-by: Waiman Long <long...@redhat.com>
---
kernel/sysctl.
the userspace will be clamped to the given
range without error if either the proc_dointvec_minmax() or the
proc_douintvec_minmax() handlers is used.
The clamped value is either the maximum or minimum value that is
closest to the input value provided by the user.
Signed-off-by: Waiman Long <l
mode. I could open up the whole positive integer space in this case
like what Eric did, but that will make the code more complex. So I
just extend IPCMNI to 2M in this case and keep similar ID generation
logic.
Waiman Long (9):
sysctl: Add flags to support min/max range clamping
proc/sysctl: P
features, if desired, to
memory controller or may be to the cpu controller instead of staying
with cpuset.
Signed-off-by: Waiman Long <long...@redhat.com>
---
Documentation/cgroup-v2.txt | 96 -
kernel/cgroup/cpuset.c | 44 ++
adds flags with support for the sched_load_balance only.
Waiman Long (2):
cpuset: Enable cpuset controller in default hierarchy
cpuset: Add cpuset.flags control knob to v2
Documentation/cgroup-v2.txt | 128
kernel/cgroup/cpuset.c
On 03/10/2018 08:16 AM, Peter Zijlstra wrote:
> On Fri, Mar 09, 2018 at 06:06:29PM -0500, Waiman Long wrote:
>> So you are talking about sched_relax_domain_level and
> That one I wouldn't be sad to see the back of.
>
>> sched_load_balance.
> This one, that's critical. And
On 03/09/2018 05:17 PM, Peter Zijlstra wrote:
> On Fri, Mar 09, 2018 at 03:43:34PM -0500, Waiman Long wrote:
>> The isolcpus= parameter just reduce the cpus available to the rests of
>> the system. The cpuset controller does look at that value and make
>> adjustment ac
On 03/09/2018 02:40 PM, Mike Galbraith wrote:
>>>
>>> If v2 is to ever supersede v1, as is the normal way of things, core
>>> functionality really should be on the v2 boat when it sails. What you
>>> left standing on the dock is critical core cpuset functionality.
>>>
>>> -Mike
>> From your
On 03/09/2018 01:17 PM, Mike Galbraith wrote:
> On Fri, 2018-03-09 at 12:45 -0500, Waiman Long wrote:
>> On 03/09/2018 11:34 AM, Mike Galbraith wrote:
>>> On Fri, 2018-03-09 at 10:35 -0500, Waiman Long wrote:
>>>> Given the fact that thread mode had been merged
On 03/09/2018 11:34 AM, Mike Galbraith wrote:
> On Fri, 2018-03-09 at 10:35 -0500, Waiman Long wrote:
>> Given the fact that thread mode had been merged into 4.14, it is now
>> time to enable cpuset to be used in the default hierarchy (cgroup v2)
>> as it is clearly threa
.
Signed-off-by: Waiman Long <long...@redhat.com>
---
Documentation/cgroup-v2.txt | 96 -
kernel/cgroup/cpuset.c | 44 +++--
2 files changed, 127 insertions(+), 13 deletions(-)
diff --git a/Documentation/cgroup-v2.txt b/Documen
On 11/27/2017 04:42 PM, Tejun Heo wrote:
> Hello, Waiman.
>
> On Mon, Nov 27, 2017 at 04:19:57PM -0500, Waiman Long wrote:
>>> Let's start just with [e]cpus and [e]mems. The flags interface looks
>>> fine but the implementations of these features are really bad and
On 11/27/2017 04:04 PM, Tejun Heo wrote:
> Hello, Waiman.
>
> Sorry about the long delay.
>
> On Fri, Oct 06, 2017 at 05:10:30PM -0400, Waiman Long wrote:
>> +Cpuset Interface Files
>> +~~
>> +
>> + cpuset.cpus
>> +A read-write
On 10/26/2017 02:12 PM, Waiman Long wrote:
> On 10/26/2017 10:39 AM, Tejun Heo wrote:
>> Hello, Waiman.
>>
>> On Wed, Oct 25, 2017 at 11:50:34AM -0400, Waiman Long wrote:
>>> Ping! Any comment on this patch?
>> Sorry about the lack of response. Here are my t
On 11/02/2017 02:08 PM, Eduardo Valentin wrote:
> On Thu, Nov 02, 2017 at 06:56:46PM +0100, Paolo Bonzini wrote:
>> On 02/11/2017 18:45, Eduardo Valentin wrote:
>>> Currently, the existing qspinlock implementation will fallback to
>>> test-and-set if the hypervisor has not set the PV_UNHALT flag.
On 10/26/2017 10:39 AM, Tejun Heo wrote:
> Hello, Waiman.
>
> On Wed, Oct 25, 2017 at 11:50:34AM -0400, Waiman Long wrote:
>> Ping! Any comment on this patch?
> Sorry about the lack of response. Here are my two thoughts.
>
> 1. I'm not really sure about the memo
On 10/06/2017 05:10 PM, Waiman Long wrote:
> Given the fact that thread mode had been merged into 4.14, it is now
> time to enable cpuset to be used in the default hierarchy (cgroup v2)
> as it is clearly threaded.
>
> The cpuset controller had experienced feature creep since its
On 10/24/2017 11:37 AM, Eduardo Valentin wrote:
> Hello Peter,
> On Tue, Oct 24, 2017 at 10:13:45AM +0200, Peter Zijlstra wrote:
>> On Mon, Oct 23, 2017 at 05:44:27PM -0700, Eduardo Valentin wrote:
>>> @@ -46,6 +48,8 @@ static inline bool virt_spin_lock(struct qspinlock *lock)
>>> if
naming
consistency.
v3:
- Further trim the additional features down to just memory_migrate.
- Update Documentation/cgroup-v2.txt.
Signed-off-by: Waiman Long <long...@redhat.com>
---
Documentation/cgroup-v2.txt | 122
kernel/cgroup/cpuset.c |
On 09/04/2017 10:40 AM, Peter Zijlstra wrote:
> On Mon, Sep 04, 2017 at 04:28:36PM +0200, Oscar Salvador wrote:
>> This is just a resend of Waiman Long's patch.
>> I could not find why it was not merged to upstream, so I thought
>> to give it another chance.
>> What
On 08/28/2017 01:58 PM, Waiman Long wrote:
> On 07/28/2017 02:34 PM, Waiman Long wrote:
>> v2->v3:
>> - Add a faster pruning rate when the free pool is closed to depletion.
>> - As suggested by James Bottomley, add an artificial delay waiting
>> loop be
On 07/28/2017 02:34 PM, Waiman Long wrote:
> v2->v3:
> - Add a faster pruning rate when the free pool is closed to depletion.
> - As suggested by James Bottomley, add an artificial delay waiting
> loop before killing a negative dentry and properly clear the
> DCACHE_
On 08/20/2017 11:23 PM, Wangkai (Kevin,C) wrote:
>
> Yes, I have add some trace info for the dentry state changed, with dentry
> flag and reference count:
>
> File create:
> [ 42.636675] dentry [_1234] 0x880230be8180 flag 0x0 ref 1 ev dentry
> alloc
> File close:
> [ 42.637421]
On 08/18/2017 05:59 AM, Wangkai (Kevin,C) wrote:
>
>>> In my patch the DCACHE_FILE_REMOVED flag was to distinguish the
>>> removed file and The closed file, I found there was no difference of a
>>> dentry between the removed file and the closed File, they all on the lru
>>> list.
>> There is a
On 08/17/2017 12:00 AM, Wangkai (Kevin,C) wrote:
>
>>>
>>> Hi Longman,
>>> I am a fresher of fsdevel, about 2 weeks before, I have joined this
>>> mail list, recently I have met the same problem of negative dentries,
>>> in my opinion, the dentries should be remove together with the files or
>>
On 08/16/2017 10:36 AM, Tejun Heo wrote:
> Hello,
>
> On Wed, Aug 16, 2017 at 10:34:05AM -0400, Waiman Long wrote:
>>> It feels weird to make this a kernel boot param when all other options
>>> are specified on mount time. Is there a reason why this can't be a
>>&
On 08/16/2017 10:29 AM, Tejun Heo wrote:
> Hello, Waiman.
>
> On Tue, Aug 15, 2017 at 01:27:20PM -0400, Waiman Long wrote:
>> +cpuset_v2_mode= [KNL] Enable cpuset v2 behavior in cpuset v1 cgroups.
>> +In v2 mode, the cpus and
On 08/16/2017 06:33 AM, Wangkai (Kevin,C) wrote:
>> -Original Message-
>> From: linux-fsdevel-ow...@vger.kernel.org
>> [mailto:linux-fsdevel-ow...@vger.kernel.org] On Behalf Of Waiman Long
>> Sent: Wednesday, August 16, 2017 1:15 AM
>> To: Alexander Viro; Jo
1 - 100 of 301 matches
Mail list logo
