Re: [PATCH v5 00/17] fs: introduce new writeback error reporting and convert ext2 and ext4 to use it

On Wed, May 31, 2017 at 08:45:23AM -0400, Jeff Layton wrote: > v5: don't retrofit old API over the new infrastructure > add fstype flag to indicate how wb errors are tracked within that fs > add more function variants that take a errseq_t "since" value > add second errseq_t to struct

Re: [RFC PATCH v2 11/17] cgroup: Implement new thread mode semantics

Hello, On Thu, Jun 01, 2017 at 05:12:42PM -0400, Waiman Long wrote: > Are you referring to keeping the no internal process restriction and > document how to work around that instead? I would like to hear what > workarounds are currently being used. What we've been talking about all along - just

Re: [RFC PATCH v2 11/17] cgroup: Implement new thread mode semantics

On 06/01/2017 04:52 PM, Tejun Heo wrote: > Hello, > > On Thu, Jun 01, 2017 at 04:48:48PM -0400, Waiman Long wrote: >> I think we are on agreement here. I should we should just document how >> userland can work around the internal process competition issue by >> setting up the cgroup hierarchy

Re: [RFC PATCH v2 11/17] cgroup: Implement new thread mode semantics

Hello, On Thu, Jun 01, 2017 at 04:48:48PM -0400, Waiman Long wrote: > I think we are on agreement here. I should we should just document how > userland can work around the internal process competition issue by > setting up the cgroup hierarchy properly. Then we can remove the no > internal

Re: [RFC PATCH v2 11/17] cgroup: Implement new thread mode semantics

On 06/01/2017 04:38 PM, Tejun Heo wrote: > Hello, > > On Thu, Jun 01, 2017 at 03:27:35PM -0400, Waiman Long wrote: >> As said in an earlier email, I agreed that masking it on the kernel side >> may not be the best solution. I offer 2 other alternatives: >> 1) Document on how to work around the

Re: [RFC PATCH v2 11/17] cgroup: Implement new thread mode semantics

Hello, On Thu, Jun 01, 2017 at 03:27:35PM -0400, Waiman Long wrote: > As said in an earlier email, I agreed that masking it on the kernel side > may not be the best solution. I offer 2 other alternatives: > 1) Document on how to work around the resource domains issue by proper > setup of the

Re: [RFC PATCH v2 11/17] cgroup: Implement new thread mode semantics

On 06/01/2017 11:10 AM, Peter Zijlstra wrote: > On Thu, Jun 01, 2017 at 10:50:42AM -0400, Tejun Heo wrote: >> Hello, Waiman. >> >> A short update. I tried making root special while keeping the >> existing threaded semantics but I didn't really like it because we >> have to couple controller

Re: [RFC PATCH v2 11/17] cgroup: Implement new thread mode semantics

On 06/01/2017 02:44 PM, Waiman Long wrote: > On 06/01/2017 11:10 AM, Peter Zijlstra wrote: >> On Thu, Jun 01, 2017 at 10:50:42AM -0400, Tejun Heo wrote: >>> Hello, Waiman. >>> >>> A short update. I tried making root special while keeping the >>> existing threaded semantics but I didn't really

Re: [PATCH v4 next 1/3] modules:capabilities: allow __request_module() to take a capability argument

On Thu, Jun 1, 2017 at 7:56 AM, Djalal Harouni wrote: > module_require_cap = 0; > > if (autoload == MODULES_AUTOLOAD_DISABLED) > return -EPERM; > > if (autoload == MODULES_AUTOLOAD_PRIVILEGED || require_cap > 0) { > if

Re: [PATCH 1/5] irq: generic-chip: provide irq_free_generic_chip()

Hi Bartosz, [auto build test WARNING on linus/master] [also build test WARNING on v4.12-rc3 next-20170601] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Bartosz-Golaszewski/irq-generic-chip

Re: [RFC PATCH v2 11/17] cgroup: Implement new thread mode semantics

Hello, Waiman. On Thu, Jun 01, 2017 at 02:44:48PM -0400, Waiman Long wrote: > > And cgroup-v2 has this 'exception' (aka wart) for the root group which > > needs to be replicated for each namespace. > > One of the changes that I proposed in my patches was to get rid of the > no internal process

Re: [RFC PATCH v2 11/17] cgroup: Implement new thread mode semantics

On 06/01/2017 11:10 AM, Peter Zijlstra wrote: > On Thu, Jun 01, 2017 at 10:50:42AM -0400, Tejun Heo wrote: >> Hello, Waiman. >> >> A short update. I tried making root special while keeping the >> existing threaded semantics but I didn't really like it because we >> have to couple controller

Re: [RFC PATCH v2 11/17] cgroup: Implement new thread mode semantics

On 06/01/2017 10:50 AM, Tejun Heo wrote: > Hello, Waiman. > > A short update. I tried making root special while keeping the > existing threaded semantics but I didn't really like it because we > have to couple controller enables/disables with threaded > enables/disables. I'm now trying a

[RFC PATCH v2 6/7] mm, oom: cgroup-aware OOM killer

Traditionally, the OOM killer is operating on a process level. Under oom conditions, it finds a process with the highest oom score and kills it. This behavior doesn't suit well the system with many running containers. There are two main issues: 1) There is no fairness between containers. A small

[RFC PATCH v2 1/7] mm, oom: refactor select_bad_process() to take memcg as an argument

The select_bad_process() function will be used further to select a process to kill in the victim cgroup. This cgroup doesn't necessary match oc->memcg, which is a cgroup, which limits were caused cgroup-wide OOM (or NULL in case of global OOM). So, refactor select_bad_process() to take a pointer

[RFC PATCH v2 7/7] mm,oom,docs: describe the cgroup-aware OOM killer

Update cgroups v2 docs. Signed-off-by: Roman Gushchin Cc: Tejun Heo Cc: Johannes Weiner Cc: Li Zefan Cc: Michal Hocko Cc: Vladimir Davydov Cc: Tetsuo Handa

[RFC PATCH v2 4/7] mm, oom: introduce oom_kill_all_tasks option for memory cgroups

This option defines whether a cgroup should be treated as a single entity by the OOM killer. If set, the OOM killer will compare the whole cgroup with other memory consumers (other cgroups and tasks in the root cgroup), and in case of an OOM will kill all belonging tasks. Disabled by default.

[RFC PATCH v2 2/7] mm, oom: split oom_kill_process() and export __oom_kill_process()

The oom_kill_process() function consists of two logical parts: a first one is responsible for considering task's children as a potential victim and some debug output. The second half is responsible for sending SIGKILL to all tasks sharing mm with the given victim. This commit splits the

[RFC PATCH v2 3/7] mm, oom: export oom_evaluate_task() and select_bad_process()

Export the oom_evaluate_task() and select_bad_process() functions to reuse them for victim selection logic in the cgroup-aware OOM killer. Signed-off-by: Roman Gushchin Cc: Tejun Heo Cc: Johannes Weiner Cc: Li Zefan Cc:

[RFC PATCH v2 5/7] mm, oom: introduce oom_score_adj for memory cgroups

Introduce a per-memory-cgroup oom_score_adj setting. A read-write single value file which exits on non-root cgroups. The default is "0". It will have a similar meaning to a per-process value, available via /proc//oom_score_adj. Should be in a range [-1000, 1000]. Signed-off-by: Roman Gushchin

Re: [RFC PATCH v2 11/17] cgroup: Implement new thread mode semantics

Hello, Peter. On Thu, Jun 01, 2017 at 05:10:45PM +0200, Peter Zijlstra wrote: > I've not had time to look at any of this. But the question I'm most > curious about is how cgroup-v2 preserves the container invariant. > > That is, each container (namespace) should look like a 'real' machine. > So

Re: [RFC PATCH v2 11/17] cgroup: Implement new thread mode semantics

On Thu, Jun 01, 2017 at 10:50:42AM -0400, Tejun Heo wrote: > Hello, Waiman. > > A short update. I tried making root special while keeping the > existing threaded semantics but I didn't really like it because we > have to couple controller enables/disables with threaded > enables/disables. I'm

Re: [PATCH v4 next 1/3] modules:capabilities: allow __request_module() to take a capability argument

On Tue, May 30, 2017 at 7:59 PM, Kees Cook wrote: [...] >>> I see a few options: >>> >>> 1) keep what you have for v4, and hope other places don't use >>> __request_module. (I'm not a fan of this.) >> >> Yes even if it is documented I wouldn't bet on it, though. :-) > > Okay,

Re: [RFC PATCH v2 11/17] cgroup: Implement new thread mode semantics

Hello, Waiman. A short update. I tried making root special while keeping the existing threaded semantics but I didn't really like it because we have to couple controller enables/disables with threaded enables/disables. I'm now trying a simpler, albeit a bit more tedious, approach which should

Re: [PATCH v13 9/9] arm64: dts: qcom: msm8916: Add debug unit

On Fri, May 26, 2017 at 12:04:13AM +0800, Leo Yan wrote: > Add debug unit on Qualcomm msm8916 based platforms, including the > DragonBoard 410c board. > > Reviewed-by: Mathieu Poirier > Signed-off-by: Leo Yan Looks fine. Acked-by: Andy Gross

Re: [PATCH v3 1/3] rtmutex: update rt-mutex-design

On 05/25/2017 01:26 PM, Alex Shi wrote: > Reviewers: Ingo Molnar, Thomas Gleixner, Thomas Duetsch, and Randy Dunlap > > @@ -779,3 +554,4 @@ Updates > --- > > This document was originally written for 2.6.17-rc3-mm1 > +was updated on 4.12-rc1 > -- This is the only change from v2