Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp4344271ybi; Tue, 30 Jul 2019 00:18:58 -0700 (PDT) X-Google-Smtp-Source: APXvYqyeDn1E4GbXYHEUBlnUETsUs542usrGpPgMKN6cR7LNXs8/5bVB5xjiNTWw95Z6dVCHe1NQ X-Received: by 2002:a63:c118:: with SMTP id w24mr106089468pgf.347.1564471138111; Tue, 30 Jul 2019 00:18:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1564471138; cv=none; d=google.com; s=arc-20160816; b=hgCB+QOGftdW1TY10zsA7yruL8rcfnmdnPS7AJPZfUFxWTZtB73yG03jlcR5e1LVfe 5teAl3tJhnvS8U+ls8csY1rlU6/3gCxD/UBUPF1yEYqHOos4GoAm0uhV2JjDh+PKNA+q 1hg+3zRGDEr5oll7GHmsHCw/WbReecl5rqk3sbDBf/iVH62i4PIOIAmVrMnS/ye6r9Ql AH9J7Mz0Azj8BE+F48/MZNjxcjDsnGsS+1idKYFG+5jgbPWwS7ghON9FOBNk/7v4vf5f IQ68n+LTwRrpdhLXagU1lflVwDF810oeQPD4ndqb4kACulLGUHGba8Q4/Ebw09j40LD5 Ai7A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from; bh=pQAkZdb2MdpLX83iuWv5XMam8kwNDm0XeAT4DOHX2Vg=; b=TOkkNIjMWHKiNyVoWJ81BaD7LnyPVGhtJj1Q9PXqg0eTl6xNBWofq8rSO0qXgtELMa ZWA0QkxU1zIx1PGcPGa+5wbUmkttZKQrzca2pZ+83le/v306ZlFHI2iKM0PjVKPVvOxa cb+NPxdYSq8TmiCmpUHD1MxgLkJ7eUZypib5fHVui5VwMQp3hpwVV1K3jRw5DLCgzWWv kOCNHFK68aVulnESzfXICFClBhS8RCOSI+MpafbiGQFkQR9TQWrT8VxhpLJ3q8ZE/ir2 ag8bd96ozocebDKYjizpw43DtGiJegNiq29FH/eS+wHJHmoO8hKwya/AGDsPFFN2Y8en zxhg== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q25si26935615pgv.114.2019.07.30.00.18.43; Tue, 30 Jul 2019 00:18:58 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729681AbfG2VIh (ORCPT + 99 others); Mon, 29 Jul 2019 17:08:37 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57054 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729298AbfG2VIh (ORCPT ); Mon, 29 Jul 2019 17:08:37 -0400 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5F3F530860C6; Mon, 29 Jul 2019 21:08:36 +0000 (UTC) Received: from llong.com (dhcp-17-160.bos.redhat.com [10.18.17.160]) by smtp.corp.redhat.com (Postfix) with ESMTP id 5E8175C1A1; Mon, 29 Jul 2019 21:08:30 +0000 (UTC) From: Waiman Long To: Peter Zijlstra , Ingo Molnar Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andrew Morton , Phil Auld , Michal Hocko , Rik van Riel , Waiman Long Subject: [PATCH v3] sched/core: Don't use dying mm as active_mm of kthreads Date: Mon, 29 Jul 2019 17:07:28 -0400 Message-Id: <20190729210728.21634-1-longman@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.44]); Mon, 29 Jul 2019 21:08:36 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 some resources that cannot be freed on a mostly idle system. Fix that by forcing the kernel threads to use init_mm as the active_mm during a kernel thread to kernel thread transition if the previous active_mm is dying (!mm_users). This will allows the freeing of resources associated with the dying mm ASAP. The presence of a kernel-to-kernel thread transition indicates that the cpu is probably idling with no higher priority user task to run. So the overhead of loading the mm_users cacheline should not really matter in this case. My testing on an x86 system showed that the mm_struct was freed within seconds after the task exited instead of staying alive for minutes or even longer on a mostly idle system before this patch. Signed-off-by: Waiman Long --- kernel/sched/core.c | 21 +++++++++++++++++++-- 1 file changed, 19 insertions(+), 2 deletions(-) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 795077af4f1a..41997e676251 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -3214,6 +3214,8 @@ static __always_inline struct rq * context_switch(struct rq *rq, struct task_struct *prev, struct task_struct *next, struct rq_flags *rf) { + struct mm_struct *next_mm = next->mm; + prepare_task_switch(rq, prev, next); /* @@ -3229,8 +3231,22 @@ context_switch(struct rq *rq, struct task_struct *prev, * * kernel -> user switch + mmdrop() active * user -> user switch + * + * kernel -> kernel and !prev->active_mm->mm_users: + * switch to init_mm + mmgrab() + mmdrop() */ - if (!next->mm) { // to kernel + if (!next_mm) { // to kernel + /* + * Checking is only done on kernel -> kernel transition + * to avoid any performance overhead while user tasks + * are running. + */ + if (unlikely(!prev->mm && + !atomic_read(&prev->active_mm->mm_users))) { + next_mm = next->active_mm = &init_mm; + mmgrab(next_mm); + goto mm_switch; + } enter_lazy_tlb(prev->active_mm, next); next->active_mm = prev->active_mm; @@ -3239,6 +3255,7 @@ context_switch(struct rq *rq, struct task_struct *prev, else prev->active_mm = NULL; } else { // to user +mm_switch: /* * sys_membarrier() requires an smp_mb() between setting * rq->curr and returning to userspace. @@ -3248,7 +3265,7 @@ context_switch(struct rq *rq, struct task_struct *prev, * finish_task_switch()'s mmdrop(). */ - switch_mm_irqs_off(prev->active_mm, next->mm, next); + switch_mm_irqs_off(prev->active_mm, next_mm, next); if (!prev->mm) { // from kernel /* will mmdrop() in finish_task_switch(). */ -- 2.18.1