From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg0-f70.google.com (mail-pg0-f70.google.com [74.125.83.70]) by kanga.kvack.org (Postfix) with ESMTP id A0C6A6B0253 for ; Mon, 18 Sep 2017 02:08:10 -0400 (EDT) Received: by mail-pg0-f70.google.com with SMTP id m30so16081856pgn.2 for ; Sun, 17 Sep 2017 23:08:10 -0700 (PDT) Received: from mx1.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id l123si4000222pfc.619.2017.09.17.23.08.09 for (version=TLS1 cipher=AES128-SHA bits=128/128); Sun, 17 Sep 2017 23:08:09 -0700 (PDT) Date: Mon, 18 Sep 2017 08:08:00 +0200 From: Michal Hocko Subject: Re: + include-linux-sched-mmh-uninline-mmdrop_async-etc.patch added to -mm tree Message-ID: <20170918060800.mh6abseaj7ndtlso@dhcp22.suse.cz> References: <59bae45a.Fmr8uSXzjRP94/2V%akpm@linux-foundation.org> <20170915070731.y5ddmgtzvjz5aot3@dhcp22.suse.cz> <20170915071228.bw5f2atahrfhj7zp@dhcp22.suse.cz> <20170915110520.69c2b26b32f03f0c34e2d2a1@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170915110520.69c2b26b32f03f0c34e2d2a1@linux-foundation.org> Sender: owner-linux-mm@kvack.org List-ID: To: Andrew Morton Cc: linux-kernel@vger.kernel.org, mingo@kernel.org, oleg@redhat.com, peterz@infradead.org, mm-commits@vger.kernel.org, linux-mm@kvack.org On Fri 15-09-17 11:05:20, Andrew Morton wrote: > On Fri, 15 Sep 2017 09:12:28 +0200 Michal Hocko 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 > > > > 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 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org