Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp1208456imm; Wed, 20 Jun 2018 13:35:57 -0700 (PDT) X-Google-Smtp-Source: ADUXVKKFTWwMJV2HFk1fVjUVTrF9KPzqjxxWS6r1LZpZ9d8LDZAW3ozUjFrnRHKT/BXf1P/yTIBB X-Received: by 2002:a17:902:4c:: with SMTP id 70-v6mr25272504pla.178.1529526957573; Wed, 20 Jun 2018 13:35:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529526957; cv=none; d=google.com; s=arc-20160816; b=iJVIn3iHSKkwdIRAg9LCGh3ItmQrWdK9vrckfRYMKdPTsmuQLyuu4xTmVWmB+pgx58 OrfEYYKn1A5+vF7pMCU+9nCG1EPyfpKiA2+Xm4LeCRK82Z5CvnQOsbGMBPuj93C48QyU ZTLVQlbG1SttUibw0954Xuq86iO4ncNDJLe8aslPH1lMGIqC4MhrQ8ixtCtHPGV0udL6 F5dDsfR81QiYq+Ij7wz1z5435HIvYYDjtt0RUJ5jH6nDRT24LFrejrDdmTVJSvQ688LN wTU+aYBQT9+ozE8ycFwN0qJ8ke4E86Ndv/v17Dqdp9YC1Ypfo9HPbisGG7TZDEsSsChU 1aKw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date:dkim-signature :arc-authentication-results; bh=aFtqx6mZlZHx0uA8dGUNzo2UtOCmwN5c3dvMqBnp/+k=; b=p78BrfH7fV5mHPkkwk4ohTF+IAOF7np1+ZWShLSEoZotGA8m7y3b16yNQQVw4nxHGn XKRFXtFwM3D1enbJVKvQcau9BrrhL7PctORgx5S8NjjG3uriKv9T9fPJjKrybbjhHInz bnJFT580ChoCKdecUaAf7atnc09L8wgX8MrqZV9rlt2DA5l2Xst6Thz5/f5Ff/p5liP6 6th9+XLOK5NcmB6chdgzfgANkQKJlJx97Z4fYiWoLSRXloknZHKf0evuNedxKL5mUfB0 /oYfDOy68pfhnI6YOmWLwNe2hVigC+aXrgQH4xfSv3I1gAUPZgSdzL9fghXIY+Qr4uQk MmBQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=qchXu39w; 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=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y21-v6si2914801pfm.1.2018.06.20.13.35.43; Wed, 20 Jun 2018 13:35:57 -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; dkim=pass header.i=@google.com header.s=20161025 header.b=qchXu39w; 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=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933217AbeFTUe4 (ORCPT + 99 others); Wed, 20 Jun 2018 16:34:56 -0400 Received: from mail-pg0-f67.google.com ([74.125.83.67]:44482 "EHLO mail-pg0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932570AbeFTUez (ORCPT ); Wed, 20 Jun 2018 16:34:55 -0400 Received: by mail-pg0-f67.google.com with SMTP id g26-v6so329091pgn.11 for ; Wed, 20 Jun 2018 13:34:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=aFtqx6mZlZHx0uA8dGUNzo2UtOCmwN5c3dvMqBnp/+k=; b=qchXu39wFaRbUManzjYxr0MjMSn0GI1d6mW53ky3agnvFv99e5Xl2h9UJvz9nM6Drf U6/eEy9MyS1qNDnLsqn8pz2GJdl3eT48xnPk+H60UIz9GC/nuERPEAeDzWbs3HgGCazG cMo7u+LiWU0urrq67ReCXpc65DqEmpdvuZe1vMYW9aaIdYaR74BWMFTG9nXBPYkCQnA0 dWWdK01rtNFBu4fBOw7fDFtb5e05EV/RMQiHALXUqZzQYfziR4p5UAOZ1Q0oUSEeWS+f Q1n1tJjxQGNPTc8i341rZUx09tSJ2gxpfAGhOtc5tvM0tGeUUnk94tkaYMMeq5poY9C4 KFwg== 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:in-reply-to:message-id :references:user-agent:mime-version; bh=aFtqx6mZlZHx0uA8dGUNzo2UtOCmwN5c3dvMqBnp/+k=; b=ZgfFRHgEizKx0mHYW0TUNzYwAptSxXK5LLUPXOOLo9WHF4R/J917zEfT9xvqI6/suQ EB3Die3k1CqqHDHp6ySJhM0OQxsLUzXp1PpqwfrNkMsJkTgB6P703uZWnXsOuJttOw6U +CqqayJsoJXikQa8LpBXEaLc6yIPvc7RDLsXKTZ18d30IulW/83+TvkWGud+LzzjCFt1 jCRsqoIHxkcOVP3134Qp2FVj4w14sMW1FBSrXp71kgigPUX/aFAeZRx5VO9DX/q36lI0 iPyh5a7ntBzpz3SL4hAGMDdUljXp1uVPwHGRKtfUnDr/zJzo6NQtRH4JIVbXQjsPyjo1 SjQA== X-Gm-Message-State: APt69E3HHvwWBTDhvscbu7B4J2/UkYLDYhFlWHVKrReDpsDkfS/a/T71 YGfEUJHeYvCQXR3XidHajS2rsA== X-Received: by 2002:a63:79c5:: with SMTP id u188-v6mr19925502pgc.111.1529526894314; Wed, 20 Jun 2018 13:34:54 -0700 (PDT) Received: from [2620:15c:17:3:3a5:23a7:5e32:4598] ([2620:15c:17:3:3a5:23a7:5e32:4598]) by smtp.gmail.com with ESMTPSA id e1-v6sm3914803pgt.71.2018.06.20.13.34.53 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 20 Jun 2018 13:34:53 -0700 (PDT) Date: Wed, 20 Jun 2018 13:34:52 -0700 (PDT) From: David Rientjes X-X-Sender: rientjes@chino.kir.corp.google.com To: Michal Hocko cc: Andrew Morton , Tetsuo Handa , "Aneesh Kumar K.V" , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [patch] mm, oom: fix unnecessary killing of additional processes In-Reply-To: <20180620130311.GM13685@dhcp22.suse.cz> Message-ID: References: <20180615065541.GA24039@dhcp22.suse.cz> <20180619083316.GB13685@dhcp22.suse.cz> <20180620130311.GM13685@dhcp22.suse.cz> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 20 Jun 2018, Michal Hocko wrote: > On Tue 19-06-18 10:33:16, Michal Hocko wrote: > [...] > > As I've said, if you are not willing to work on a proper solution, I > > will, but my nack holds for this patch until we see no other way around > > existing and real world problems. > > OK, so I gave it a quick try and it doesn't look all that bad to me. > This is only for blockable mmu notifiers. I didn't really try to > address all the problems down the road - I mean some of the blocking > notifiers can check the range in their interval tree without blocking > locks. It is quite probable that only few ranges will be of interest, > right? > > So this is only to give an idea about the change. It probably even > doesn't compile. Does that sound sane? It depends on how invasive we want to make this, it should result in more memory being freeable if the invalidate callbacks can guarantee that they won't block. I think it's much more invasive than the proposed patch, however. For the same reason as the mm->mmap_sem backoff, however, this should retry for a longer period of time than HZ. If we can't grab mm->mmap_sem the first five times with the trylock because of writer queueing, for example, then we only have five attempts for each blockable mmu notifier invalidate callback, and any of the numerous locks it can take to declare it will not block. Note that this doesn't solve the issue with setting MMF_OOM_SKIP too early on processes with mm->mmap_sem contention or now invalidate callbacks that will block; the decision that the mm cannot be reaped should come much later. > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > index 6bcecc325e7e..ac08f5d711be 100644 > --- a/arch/x86/kvm/x86.c > +++ b/arch/x86/kvm/x86.c > @@ -7203,8 +7203,9 @@ static void vcpu_load_eoi_exitmap(struct kvm_vcpu *vcpu) > kvm_x86_ops->load_eoi_exitmap(vcpu, eoi_exit_bitmap); > } > > -void kvm_arch_mmu_notifier_invalidate_range(struct kvm *kvm, > - unsigned long start, unsigned long end) > +int kvm_arch_mmu_notifier_invalidate_range(struct kvm *kvm, > + unsigned long start, unsigned long end, > + bool blockable) > { > unsigned long apic_address; > > @@ -7215,6 +7216,8 @@ void kvm_arch_mmu_notifier_invalidate_range(struct kvm *kvm, > apic_address = gfn_to_hva(kvm, APIC_DEFAULT_PHYS_BASE >> PAGE_SHIFT); > if (start <= apic_address && apic_address < end) > kvm_make_all_cpus_request(kvm, KVM_REQ_APIC_PAGE_RELOAD); > + > + return 0; > } > > void kvm_vcpu_reload_apic_access_page(struct kvm_vcpu *vcpu) Auditing the first change in the patch, this is incorrect because kvm_make_all_cpus_request() for KVM_REQ_APIC_PAGE_RELOAD can block in kvm_kick_many_cpus() and that is after kvm_make_request() has been done.