Received: by 2002:a25:e7d8:0:0:0:0:0 with SMTP id e207csp2581028ybh; Mon, 9 Mar 2020 08:43:36 -0700 (PDT) X-Google-Smtp-Source: ADFU+vsSXVv1aT+ainG96paB1FFBQ0r0rNBl6QUQjCj2eJbtkDhHG1wjRJu4jEP/GmDXnQ8JQvUc X-Received: by 2002:aca:3354:: with SMTP id z81mr12043192oiz.129.1583768616787; Mon, 09 Mar 2020 08:43:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1583768616; cv=none; d=google.com; s=arc-20160816; b=GgF6syP4rxlfF99Sr5uNziJNCPCBm/3FX8NOWuJfPK/dh3x3Izejer3ebVURhLc7Jq 7LQB2OzoXw/YIzD707IKW8oZz9b9W6Q8DcUE0aVyXJ9SeJEw82xV0AfV6CBuT+aOqx4s HzVnVVrxroQkj4cvdD2v8mde62TF036aOPTvefGbqeMFabod2eJvCk7y3bwb1UtzuNjH XnFbOOGdVILKpkDRXCLcFL/dvmcYF2HT0egxNLeECitBRSxaoFH4VOFYsHDReh498z7g gstpDXycvDyj7n7IWlG6jEVSAS57JirT3SffAxN4nXzTCiyzBAVI/C9ZDVOTfuD3B7z4 NmIg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=zs16VHvgkjT4lDi3wZLtq0SSScr9Ebg9Kp/dA4/pShE=; b=Yq2wPCkMtkNOeOpNL/kCDc4ejVwm2HYeSndYBEMs0h2RuxanZDb34PyMKH8yZhnXBZ 7IKqa2uO1tglDDw/BJ7zWbPmFWhMS4A6h0VpbhiSn6Y6ILSIRnwHL8AWLuqfNfFd7evM RGivgBc+FnTkbHOLIG3mCQ173vIVwK7bBUVQn+A1KzvbvVSa7i7zQrmMgcRAUWBLHHKd eMN6j/ibEtn9C9bpuP170OqM78cY4R8RLISwmHnR0jjWbkpkRaKcN3AfQg3bZ+AZB9vd RW9Tg4wNzx+Xlarcr2FPZBoc8CxFBuOUXUdNZDkAG2/EI0GzMw+gFcBoWdeGFoTPu3zu a9yg== 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 f20si6637427oti.224.2020.03.09.08.43.24; Mon, 09 Mar 2020 08:43:36 -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 S1727054AbgCIPmy (ORCPT + 99 others); Mon, 9 Mar 2020 11:42:54 -0400 Received: from mx2.suse.de ([195.135.220.15]:39340 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726804AbgCIPmx (ORCPT ); Mon, 9 Mar 2020 11:42:53 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id C77DDAD07; Mon, 9 Mar 2020 15:42:51 +0000 (UTC) Subject: Re: [PATCH v7 7/7] mm/madvise: allow KSM hints for remote API To: Oleksandr Natalenko , Michal Hocko Cc: 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 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> From: Vlastimil Babka Message-ID: <34f812b8-df54-eaad-5cf0-335f07da55c6@suse.cz> Date: Mon, 9 Mar 2020 16:42:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <20200309151932.6sjwq6bucbu6zsea@butterfly.localdomain> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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? >> >> -- >> Michal Hocko >> SUSE Labs >> >