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 fi
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 c
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 prope
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 process
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 reso
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 cgrou
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 enable
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 like
On 06/01/2017 02:47 PM, Tejun Heo wrote:
> 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 wa
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 (prefix != NULL && *pre
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
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 co
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 enable
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 simpler,
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
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 t
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
Cc: kernel-t...@fb.com
Cc: cgro...@vger.kernel.org
Cc: linux-doc@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: linux...@kvack.or
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.
Si
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 oom_kill_p
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: Michal Hocko
Cc: Vladimir Davydov
Cc: Tetsuo Handa
Cc: kernel-t...@fb.c
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
Cc
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 j
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 no
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, we seem to agree: we'
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 le
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
--
To unsubscribe from this list: send the line "un
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 versi
27 matches
Mail list logo