Re: [v8 0/4] cgroup-aware OOM killer

2017-09-21 Thread Johannes Weiner
On Thu, Sep 21, 2017 at 02:17:25PM -0700, David Rientjes wrote: > On Thu, 21 Sep 2017, Johannes Weiner wrote: > > > That's a ridiculous nak. > > > > The fact that this patch series doesn't solve your particular problem > > is not a technical argument to *reject* somebody else's work to solve > >

Re: [v8 0/4] cgroup-aware OOM killer

2017-09-21 Thread David Rientjes
On Thu, 21 Sep 2017, Johannes Weiner wrote: > That's a ridiculous nak. > > The fact that this patch series doesn't solve your particular problem > is not a technical argument to *reject* somebody else's work to solve > a different problem. It's not a regression when behavior is completely >

Re: [PATCH v2] Documentation: rewrite confusing statement about memory barriers

2017-09-21 Thread Guilherme G. Piccoli
On 09/21/2017 04:50 PM, Paul E. McKenney wrote: > On Thu, Sep 21, 2017 at 04:29:01PM -0300, Guilherme G. Piccoli wrote: >> In this specific portion of the write memory barriers description, >> the documentation mentions sequential order of stores, which is >> confusing since sequential ordering is

Re: [PATCH v2] Documentation: rewrite confusing statement about memory barriers

2017-09-21 Thread Paul E. McKenney
On Thu, Sep 21, 2017 at 04:29:01PM -0300, Guilherme G. Piccoli wrote: > In this specific portion of the write memory barriers description, > the documentation mentions sequential order of stores, which is > confusing since sequential ordering is not guaranteed. > > This patch tries to improve the

[PATCH v2] Documentation: rewrite confusing statement about memory barriers

2017-09-21 Thread Guilherme G. Piccoli
In this specific portion of the write memory barriers description, the documentation mentions sequential order of stores, which is confusing since sequential ordering is not guaranteed. This patch tries to improve the doc in order to avoid any mis-understanding. Cc: Paul E. McKenney

[PATCH] Documentation: rewrite confusing statement about memory barriers

2017-09-21 Thread Guilherme G. Piccoli
In this specific portion of the write memory barriers description, the documentation mentions sequential order of stores, which is confusing since sequential ordering is not guaranteed. This patch tries to improve the doc in order to avoid any mis-understanding. Signed-off-by: Guilherme G.

Re: [v8 0/4] cgroup-aware OOM killer

2017-09-21 Thread Johannes Weiner
On Mon, Sep 11, 2017 at 01:44:39PM -0700, David Rientjes wrote: > On Mon, 11 Sep 2017, Roman Gushchin wrote: > > > This patchset makes the OOM killer cgroup-aware. > > > > v8: > > - Do not kill tasks with OOM_SCORE_ADJ -1000 > > - Make the whole thing opt-in with cgroup mount option control

Re: [PATCH] scripts: kernel-doc: fix nexted handling

2017-09-21 Thread Markus Heiser
> Jon, > > While documenting some DVB demux headers, I noticed the above bug. > > scripts/kernel-doc | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/scripts/kernel-doc b/scripts/kernel-doc > index 9d3eafea58f0..15f934a23d1d 100755 > --- a/scripts/kernel-doc > +++

Re: [PATCH v5 0/6] Add HiSilicon SoC uncore Performance Monitoring Unit driver

2017-09-21 Thread Zhangshaokun
Hi Mark/Will, Appreciate any comments from you. Thanks, Shaokun On 2017/8/22 16:07, Shaokun Zhang wrote: > This patchset adds support for HiSilicon SoC uncore PMUs driver. It > includes L3C, Hydra Home Agent (HHA) and DDRC. > > Changes in v5: > * remove unnecessary name/num_events member in

Re: [v8 0/4] cgroup-aware OOM killer

2017-09-21 Thread David Rientjes
On Mon, 18 Sep 2017, Roman Gushchin wrote: > > As said in other email. We can make priorities hierarchical (in the same > > sense as hard limit or others) so that children cannot override their > > parent. > > You mean they can set the knob to any value, but parent's value is enforced, > if it's

Re: [v8 0/4] cgroup-aware OOM killer

2017-09-21 Thread David Rientjes
On Wed, 20 Sep 2017, Roman Gushchin wrote: > > It's actually much more complex because in our environment we'd need an > > "activity manager" with CAP_SYS_RESOURCE to control oom priorities of user > > subcontainers when today it need only be concerned with top-level memory > > cgroups. Users