Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp3884411ybi; Mon, 29 Jul 2019 14:36:16 -0700 (PDT) X-Google-Smtp-Source: APXvYqxGpj/IiK2SHfxKC7BbDWn5REYtzVIirWQzvpeGrrXYMsUkWD36gkjdgXvA/HrpTQSWXd3Y X-Received: by 2002:a17:902:8696:: with SMTP id g22mr109183060plo.249.1564436176907; Mon, 29 Jul 2019 14:36:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1564436176; cv=none; d=google.com; s=arc-20160816; b=gjj0Q/zxzGXtjZc51Ozjfk63MSf8+Tpk+Uk9yjZb7AxqRGHWVH66QyhJ/WBdWnnxGJ 4h3uJb0NI2skNf4KoDfYH7H4xnyMzhDD9BBD71KeQVIDuDesa0+nTudvJinTfxx4rqJZ Eah4bBFj+uW8ZKMTA9ltyKGM3IWiIabIH84nmzms7On3XcZ2I09Q8d0TLFeG6SUKyVlz cjkC28vvFeLqy3Oio7J3xgjlOALVsUW4EhEQUYv4DrvTZWLpoFx0K9yoT7Dr7+HP6aF1 WePa67JtYDWtJCg+wQCfyGlrxZQLPEnnXXwtIYD6PNQ26oHinHkfqAnCNqooKFuBTkW7 i+ZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=6Jl9DS1EKc0OjCFMJqDd7SL7yh8rMk8qwq52fLhcChE=; b=kwwXzawUaeOsYdQTnEHdoeKLBE8cLs8VoxfDMztPvMEbc/AZ/NpNJuIz/SENoADcZt UX9E/iO3asF7qA6q5PXAf73AcJEgKCGFDeggagaE4FJqAbBV/OFTB4SMjVM1wVz7t9sR L3Og/ooJhCkcp+DLoawMP3paYmQv2KYjD4WG3bIJa8FU6mQvpwiQUo+QN2TawV8E7ZHq QdWQKzg8HCEg/qyavSX/PDdVYroe4QbNfJ0Icq6XlOAYR8E+Bv8FCUJXRZp92WtL8BFH DRdUN/IStAjYs9NUhfvBzIRsLrkCJiS8mcMfyvneH/61Cl9VS8eTUxFROVxDlcjSlwrt Ob4w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p95si26865617pjp.4.2019.07.29.14.36.02; Mon, 29 Jul 2019 14:36:16 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730138AbfG2Vdp (ORCPT + 99 others); Mon, 29 Jul 2019 17:33:45 -0400 Received: from foss.arm.com ([217.140.110.172]:52652 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729545AbfG2Vdp (ORCPT ); Mon, 29 Jul 2019 17:33:45 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id CD299337; Mon, 29 Jul 2019 14:33:44 -0700 (PDT) Received: from e107158-lin.cambridge.arm.com (e107158-lin.cambridge.arm.com [10.1.194.55]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C95423F71F; Mon, 29 Jul 2019 14:33:43 -0700 (PDT) Date: Mon, 29 Jul 2019 22:33:41 +0100 From: Qais Yousef To: Waiman Long Cc: Peter Zijlstra , Ingo Molnar , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andrew Morton , Phil Auld Subject: Re: [PATCH v2] sched/core: Don't use dying mm as active_mm of kthreads Message-ID: <20190729213341.pacbqtcsdfmkdbsr@e107158-lin.cambridge.arm.com> References: <20190727171047.31610-1-longman@redhat.com> <20190729081800.qbamrvsf4rjna656@e107158-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20171215 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07/29/19 17:06, Waiman Long wrote: > On 7/29/19 4:18 AM, Qais Yousef wrote: > > On 07/27/19 13:10, Waiman Long wrote: > >> It was found that a dying mm_struct where the owning task has exited > >> can stay on as active_mm of kernel threads as long as no other user > >> tasks run on those CPUs that use it as active_mm. This prolongs the > >> life time of dying mm holding up memory and other resources like swap > >> space that cannot be freed. > >> > >> Fix that by forcing the kernel threads to use init_mm as the active_mm > >> if the previous active_mm is dying. > >> > >> The determination of a dying mm is based on the absence of an owning > >> task. The selection of the owning task only happens with the CONFIG_MEMCG > >> option. Without that, there is no simple way to determine the life span > >> of a given mm. So it falls back to the old behavior. > > I don't really know a lot about this code, but does the owner field has to > > depend on CONFIG_MEMCG? ie: can't the owner be always set? > > > Yes, the owner field is only used and defined when CONFIG_MEMCG is on. I guess this is the simpler answer of it's too much work to take it out of CONFIG_MEMCG. Anyway, given the direction of the thread this is moot now :-) Thanks! -- Qais Yousef