lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sat, 22 Aug 2020 22:49:19 -0400 From: Waiman Long <longman@...hat.com> To: Chris Down <chris@...isdown.name>, peterz@...radead.org Cc: Michal Hocko <mhocko@...e.com>, Andrew Morton <akpm@...ux-foundation.org>, Johannes Weiner <hannes@...xchg.org>, Vladimir Davydov <vdavydov.dev@...il.com>, Jonathan Corbet <corbet@....net>, Alexey Dobriyan <adobriyan@...il.com>, Ingo Molnar <mingo@...nel.org>, Juri Lelli <juri.lelli@...hat.com>, Vincent Guittot <vincent.guittot@...aro.org>, linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org, linux-fsdevel@...r.kernel.org, cgroups@...r.kernel.org, linux-mm@...ck.org Subject: Re: [RFC PATCH 0/8] memcg: Enable fine-grained per process memory control On 8/18/20 6:17 AM, Chris Down wrote: > peterz@...radead.org writes: >> But then how can it run-away like Waiman suggested? > > Probably because he's not running with that commit at all. We and > others use this to prevent runaway allocation on a huge range of > production and desktop use cases and it works just fine. > >> /me goes look... and finds MEMCG_MAX_HIGH_DELAY_JIFFIES. >> >> That's a fail... :-( > > I'd ask that you understand a bit more about the tradeoffs and > intentions of the patch before rushing in to declare its failure, > considering it works just fine :-) > > Clamping the maximal time allows the application to take some action > to remediate the situation, while still being slowed down > significantly. 2 seconds per allocation batch is still absolutely > plenty for any use case I've come across. If you have evidence it > isn't, then present that instead of vague notions of "wrongness". > Sorry for the late reply. I ran some test on the latest kernel and and it seems to work as expected. I was running the test on an older kernel that doesn't have this patch and I was not aware of it before hand. Sorry for the confusion. Cheers, Longman
Powered by blists - more mailing lists