Linux kernel -stable discussions
 help / color / mirror / Atom feed
* Re: [PATCH] memcg: fix per_node_info cleanup
       [not found] <20180406100906.17790-1-mhocko@kernel.org>
@ 2018-04-10 13:50 ` Sasha Levin
  2018-04-10 14:01   ` Michal Hocko
  0 siblings, 1 reply; 4+ messages in thread
From: Sasha Levin @ 2018-04-10 13:50 UTC (permalink / raw)
  To: Sasha Levin, Michal Hocko, Michal Hocko, Andrew Morton
  Cc: Johannes Weiner, stable@vger.kernel.org

Hi,

[This is an automated email]

This commit has been processed because it contains a "Fixes:" tag,
fixing commit: 00f3ca2c2d66 mm: memcontrol: per-lruvec stats infrastructure.

The bot has also determined it's probably a bug fixing patch. (score: 40.3266)

The bot has tested the following trees: v4.16.1, v4.15.16, v4.14.33.

v4.16.1: Build OK!
v4.15.16: Failed to apply! Possible dependencies:
    a983b5ebee57 ("mm: memcontrol: fix excessive complexity in memory.stat reporting")

v4.14.33: Failed to apply! Possible dependencies:
    a983b5ebee57 ("mm: memcontrol: fix excessive complexity in memory.stat reporting")


--
Thanks,
Sasha

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] memcg: fix per_node_info cleanup
  2018-04-10 13:50 ` [PATCH] memcg: fix per_node_info cleanup Sasha Levin
@ 2018-04-10 14:01   ` Michal Hocko
  2018-04-10 17:55     ` Sasha Levin
  0 siblings, 1 reply; 4+ messages in thread
From: Michal Hocko @ 2018-04-10 14:01 UTC (permalink / raw)
  To: Sasha Levin; +Cc: Andrew Morton, Johannes Weiner, stable@vger.kernel.org

On Tue 10-04-18 13:50:30, Sasha Levin wrote:
> Hi,
> 
> [This is an automated email]
> 
> This commit has been processed because it contains a "Fixes:" tag,
> fixing commit: 00f3ca2c2d66 mm: memcontrol: per-lruvec stats infrastructure.

Yes and the changelog states conditions which are quite hard to achieve
to have this patch in the stable tree. So I am not really convinced it
is worth backporting even though the patch itself is trivial.
-- 
Michal Hocko
SUSE Labs

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] memcg: fix per_node_info cleanup
  2018-04-10 14:01   ` Michal Hocko
@ 2018-04-10 17:55     ` Sasha Levin
  2018-04-10 20:37       ` Michal Hocko
  0 siblings, 1 reply; 4+ messages in thread
From: Sasha Levin @ 2018-04-10 17:55 UTC (permalink / raw)
  To: Michal Hocko; +Cc: Andrew Morton, Johannes Weiner, stable@vger.kernel.org

On Tue, Apr 10, 2018 at 04:01:32PM +0200, Michal Hocko wrote:
>On Tue 10-04-18 13:50:30, Sasha Levin wrote:
>> Hi,
>>
>> [This is an automated email]
>>
>> This commit has been processed because it contains a "Fixes:" tag,
>> fixing commit: 00f3ca2c2d66 mm: memcontrol: per-lruvec stats infrastructure.
>
>Yes and the changelog states conditions which are quite hard to achieve
>to have this patch in the stable tree. So I am not really convinced it
>is worth backporting even though the patch itself is trivial.

Quite hard to achieve, but the changelog also indicated that this was
actually hit and is not just theoretical. Is there something that will
prevent this from happening on "real" workloads?

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] memcg: fix per_node_info cleanup
  2018-04-10 17:55     ` Sasha Levin
@ 2018-04-10 20:37       ` Michal Hocko
  0 siblings, 0 replies; 4+ messages in thread
From: Michal Hocko @ 2018-04-10 20:37 UTC (permalink / raw)
  To: Sasha Levin; +Cc: Andrew Morton, Johannes Weiner, stable@vger.kernel.org

On Tue 10-04-18 17:55:13, Sasha Levin wrote:
> On Tue, Apr 10, 2018 at 04:01:32PM +0200, Michal Hocko wrote:
> >On Tue 10-04-18 13:50:30, Sasha Levin wrote:
> >> Hi,
> >>
> >> [This is an automated email]
> >>
> >> This commit has been processed because it contains a "Fixes:" tag,
> >> fixing commit: 00f3ca2c2d66 mm: memcontrol: per-lruvec stats infrastructure.
> >
> >Yes and the changelog states conditions which are quite hard to achieve
> >to have this patch in the stable tree. So I am not really convinced it
> >is worth backporting even though the patch itself is trivial.
> 
> Quite hard to achieve, but the changelog also indicated that this was
> actually hit and is not just theoretical. Is there something that will
> prevent this from happening on "real" workloads?

Well, small allocations do not really fail and it would take to
configure a really large NUMA system to achieve the same. So I am
skeptical.

-- 
Michal Hocko
SUSE Labs

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2018-04-10 20:37 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <20180406100906.17790-1-mhocko@kernel.org>
2018-04-10 13:50 ` [PATCH] memcg: fix per_node_info cleanup Sasha Levin
2018-04-10 14:01   ` Michal Hocko
2018-04-10 17:55     ` Sasha Levin
2018-04-10 20:37       ` Michal Hocko

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox