From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8A70AC10F27 for ; Mon, 9 Mar 2020 16:03:36 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4D8AA208C3 for ; Mon, 9 Mar 2020 16:03:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4D8AA208C3 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id EBD716B0005; Mon, 9 Mar 2020 12:03:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E6E006B0006; Mon, 9 Mar 2020 12:03:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D5D0E6B0007; Mon, 9 Mar 2020 12:03:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0070.hostedemail.com [216.40.44.70]) by kanga.kvack.org (Postfix) with ESMTP id BE27A6B0005 for ; Mon, 9 Mar 2020 12:03:35 -0400 (EDT) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 8A090181AC9C6 for ; Mon, 9 Mar 2020 16:03:35 +0000 (UTC) X-FDA: 76576293990.30.mint50_76a24c8d4ed4d X-HE-Tag: mint50_76a24c8d4ed4d X-Filterd-Recvd-Size: 5410 Received: from mail-wm1-f68.google.com (mail-wm1-f68.google.com [209.85.128.68]) by imf30.hostedemail.com (Postfix) with ESMTP for ; Mon, 9 Mar 2020 16:03:35 +0000 (UTC) Received: by mail-wm1-f68.google.com with SMTP id n2so64138wmc.3 for ; Mon, 09 Mar 2020 09:03:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=4Vb8vw+xlPzxP4hGQgzGpAoq0a99lvU78mWwnn4o6e4=; b=oLvBnPlLfSJBZt0IFhHxbvGlJG0C0Bnf5s0Un86ShzouLAH6SScRdwwRgY1ij2LA3K QGPniUlj/zsR/sCflQmfO0yt6kqr5hF0sfB2Dhp/B8l5VdSaex3+FuIjvRubDsa9jOud O1+gb/bDuoON7+S8S42+QAd9Okv/8+XvUkLSJYsZd7aovhWUtfNllpLv57EDlChSRksn ixGd4dfwB9uOZlzwM1rFqMrpJPFmyXt+yrE40/bTLsbkzrifJCQFLbb22Ay82Of5F2k1 ofrm67l03T9P0L8IamqLo3w7m6NCh9x2gchWbgyOxC5AzHq5jqtabqJjznisr1bnSWlF S8uQ== X-Gm-Message-State: ANhLgQ1l9cnB7GBiopUyjFa04MdTqn6ctKkrYrjDG2vy75KTC1RQv7HV /zF/qYlmiOa9AQO6p5EI+0Q= X-Google-Smtp-Source: ADFU+vs/vVARoowvzHwEBELNyzAhXmxMxbsk+sHC8tw965L4Ewe24G/EJ0vjZZKrFGdJ/VZOLA4eKQ== X-Received: by 2002:a05:600c:215:: with SMTP id 21mr20616319wmi.119.1583769813931; Mon, 09 Mar 2020 09:03:33 -0700 (PDT) Received: from localhost (prg-ext-pat.suse.com. [213.151.95.130]) by smtp.gmail.com with ESMTPSA id 61sm12198177wrd.58.2020.03.09.09.03.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Mar 2020 09:03:33 -0700 (PDT) Date: Mon, 9 Mar 2020 17:03:32 +0100 From: Michal Hocko To: Vlastimil Babka Cc: Oleksandr Natalenko , Minchan Kim , Andrew Morton , LKML , linux-mm , linux-api@vger.kernel.org, Suren Baghdasaryan , Tim Murray , Daniel Colascione , Sandeep Patil , Sonny Rao , Brian Geffon , Johannes Weiner , Shakeel Butt , John Dias , Joel Fernandes , Jann Horn , alexander.h.duyck@linux.intel.com, sj38.park@gmail.com, SeongJae Park Subject: Re: [PATCH v7 7/7] mm/madvise: allow KSM hints for remote API Message-ID: <20200309160332.GS8447@dhcp22.suse.cz> References: <20200302193630.68771-1-minchan@kernel.org> <20200302193630.68771-8-minchan@kernel.org> <2a66abd8-4103-f11b-06d1-07762667eee6@suse.cz> <20200306134146.mqiyvsdnqty7so53@butterfly.localdomain> <20200309131117.anvyjszaigpoz2kp@butterfly.localdomain> <20200309150815.GR8447@dhcp22.suse.cz> <20200309151932.6sjwq6bucbu6zsea@butterfly.localdomain> <34f812b8-df54-eaad-5cf0-335f07da55c6@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <34f812b8-df54-eaad-5cf0-335f07da55c6@suse.cz> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon 09-03-20 16:42:43, Vlastimil Babka wrote: > On 3/9/20 4:19 PM, Oleksandr Natalenko wrote: > > On Mon, Mar 09, 2020 at 04:08:15PM +0100, Michal Hocko wrote: > >> On Mon 09-03-20 14:11:17, Oleksandr Natalenko wrote: > >> > On Fri, Mar 06, 2020 at 05:08:18PM +0100, Vlastimil Babka wrote: > >> [...] > >> > > Dunno, it's nice to react to signals quickly, for any proces that gets them, no? > >> > > >> > So, do you mean something like this? > >> > > >> > === > >> > diff --git a/mm/ksm.c b/mm/ksm.c > >> > index 363ec8189561..b39c237cfcf4 100644 > >> > --- a/mm/ksm.c > >> > +++ b/mm/ksm.c > >> > @@ -849,7 +849,8 @@ static int unmerge_ksm_pages(struct vm_area_struct *vma, > >> > for (addr = start; addr < end && !err; addr += PAGE_SIZE) { > >> > if (ksm_test_exit(vma->vm_mm)) > >> > break; > >> > - if (signal_pending(current)) > >> > + if (signal_pending(current) || > >> > + signal_pending(rcu_dereference(vma->vm_mm->owner))) > >> > err = -ERESTARTSYS; > >> > else > >> > err = break_ksm(vma, addr); > >> > === > >> > >> This is broken because mm might be attached to different tasks. > >> AFAIU this check is meant to allow quick backoff of the _calling_ > >> process so that it doesn't waste time when the context is killed > >> already. I do not understand why should we care about any other context > >> here? What is the actual problem this would solve? > > > > I agree with you, but still trying to understand what does Vlastimil mean > > :). > > Well you wondered if we should stop caring about current, and I said that > probably wouldn't be nice. > As for caring about the other task, patch 3/7 does that for > (MADV_COLD|MADV_PAGEOUT) so I just pointed out that the KSM case doesn't. AFAIU > if we don't check the signals, we might be blocking the killed task from exiting? I would have to double check but I do not think this would be a problem because the remote task should take mmget to prevent address space to vanish under its feet. That should also rule out the exclusive mmap_sem usage from the exit path. -- Michal Hocko SUSE Labs