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: Mon, 18 Sep 2017 08:08:00 +0200 From: Michal Hocko <mhocko@...nel.org> To: Andrew Morton <akpm@...ux-foundation.org> Cc: linux-kernel@...r.kernel.org, mingo@...nel.org, oleg@...hat.com, peterz@...radead.org, mm-commits@...r.kernel.org, linux-mm@...ck.org Subject: Re: + include-linux-sched-mmh-uninline-mmdrop_async-etc.patch added to -mm tree On Fri 15-09-17 11:05:20, Andrew Morton wrote: > On Fri, 15 Sep 2017 09:12:28 +0200 Michal Hocko <mhocko@...nel.org> wrote: > > > On Fri 15-09-17 09:07:31, Michal Hocko wrote: > > > On Thu 14-09-17 13:19:38, Andrew Morton wrote: > > > > From: Andrew Morton <akpm@...ux-foundation.org> > > > > Subject: include/linux/sched/mm.h: uninline mmdrop_async(), etc > > > > > > > > mmdrop_async() is only used in fork.c. Move that and its support > > > > functions into fork.c, uninline it all. > > > > > > Is this really an improvement? Why do we want to discourage more code > > > paths to use mmdrop_async? It sounds like a useful api and it has been > > > removed only because it lost its own user in oom code. Now that we have > > > a user I would just keep it where it was before. > > > > Dohh, I have mixed mmput_async with mmdrop_async. Anyway I still think > > that this is universal enough to have it in a header rather than hiding > > it in fork.c > > Async free is a hack. It consumes more resources (runtime and memory) > than a synchronous free. It introduces a risk of memory exhaustion > when an unbounded number of async frees are pending, not yet serviced. > It introduces a risk of unbounded latency when an unbounded number of > async frees are serviced by the kernel thread. It is our standard technique of postponing an action to a more relaxed context when we cannot afford an action from the current context. > Synchronous frees are simply better, so we shouldn't encourage the use > of async frees. No questions about that. But we have a clear demand for the deferred implementation as well. And we have learned that having our own private, thing usually leads people to invent their own wheel. -- Michal Hocko SUSE Labs
Powered by blists - more mailing lists