Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp71792ybt; Tue, 30 Jun 2020 15:05:17 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzcsJmRH3LRJ8VxCiGP2gBprO/6UzPvePrqFXoyRm1tQ1er3q5ysf7OVY11P87a9r3XPK9n X-Received: by 2002:aa7:dc46:: with SMTP id g6mr22071530edu.194.1593554352552; Tue, 30 Jun 2020 14:59:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593554352; cv=none; d=google.com; s=arc-20160816; b=beWPvbD88loeWTy2R8sWbO/nmt9AuYLIWD5Vy+cP1j7eFk2tlT9sosTzpzCYW23Cqi UqB+OnIkY5sbWNz0myv4Ncp7oIUJbpUTGFnguUSTH9v9fsME5yuk8SY+bDph7e/NhqF9 DZcwsyJGt0G9y7lblacCgTYH2d1Vb4vj2bPkiT7zPfAihoMVM6/6kmugVbruXm45OXed m6n+dFr1cDX/1QhYvql/Ve2JOGBGzIEIw7uGR0WzE/0iq/MFmt51Wc1LfPOMWOQnyWIZ YAAxLJmCGIgPbO3eMSqRmOjJOF1xjTShFMV78DTGpOlaSTqbMx4YLNmmDCSV8J1gboSd Sk+A== 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; bh=7IVzLJAup4VkDuAt/OunGpXP5pyiE7ynN3kodoEoQWE=; b=NNtAildciSrOmPx2cqmfz8yTx+GOTebwXYF/JkLUoqdM2qnIN2MmtPl1EpsxAsfxan 9QpS876bczWNlAiEVvu8SiB76A5ZiWmSDNFaScX4VFVHh5G6R/WbscpMD8gCDzdfvaG5 ZvPXrQPODYvT86btdqYSvGgGAtF9UCJsCrgsGz/5DXMYdZgib/j3w0G93edTdzvDidUX qJNSn8YBRI4vm1N3FFQl0ANVRXisQaS1p6ySW2NOzKoxalOwTtI8fcK04gDW4UmWuvnn SqqSzpMVKqpvYZQweHIQkeuvv9yZ6AC3V/Y6pbjSS4SOfLjS/J4yx8FoPQQ38Otgtt4O Yktg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=QUdibEW+; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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. [23.128.96.18]) by mx.google.com with ESMTP id m29si3063025edb.178.2020.06.30.14.58.49; Tue, 30 Jun 2020 14:59:12 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=QUdibEW+; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S1728017AbgF3VF2 (ORCPT + 99 others); Tue, 30 Jun 2020 17:05:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58288 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726084AbgF3VF1 (ORCPT ); Tue, 30 Jun 2020 17:05:27 -0400 Received: from mail-pj1-x1043.google.com (mail-pj1-x1043.google.com [IPv6:2607:f8b0:4864:20::1043]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9EAB9C061755 for ; Tue, 30 Jun 2020 14:05:27 -0700 (PDT) Received: by mail-pj1-x1043.google.com with SMTP id o22so4981752pjw.2 for ; Tue, 30 Jun 2020 14:05:27 -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=7IVzLJAup4VkDuAt/OunGpXP5pyiE7ynN3kodoEoQWE=; b=QUdibEW+tmy14fhQZz/MEX47zW5zuODLO2iw5hCK+fuz6atzNqZS7wfwq88aa5gGNZ tcoL4SeyvbY2vZmuDYF3SJACAtGQNg2IUJvfpnMncjKaqSpG+Ag8Up58cx+CC5r0x0by oWkkAUayol9EAh71nHOO/Cyzkwxn0qRfwv8rIwAUjTLk55vymD83jgXIJjUjDplKPxzQ twNxTc0A2bK/TrTAepZMJ8yD2igZBAP5033cejEg5xi9B5nra3awyGB6anyEkxBLnPth xMLNrjI0kueaOX2OFYgDwPamPjl7Tj5L+9O1YReWNl93rCB3emRFthqAk9voQHii1UyL 1iLQ== 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=7IVzLJAup4VkDuAt/OunGpXP5pyiE7ynN3kodoEoQWE=; b=THvUTBumXe2ohCp4cURbFgKM0XJ13evyjPJ6HfMsUsjwN3uBjsCFpzK9mHw4e9XhB9 bHTdV2TYuYZXt2W+cYPc81XI7qu/jG2SPVyHH+cEnIApf3z30a6+hSFsARA4PyQawn6r Pg8SwkGAqDhum5hUgN4te3yuC7QpEHHoeD97EN1VPj+6B6dg51duViuXkHpaReawl7ku HNSnGl8T0cIXEHm13+ogofJXWZOA+Jkkr93jtf8XdC3GTjMwDdfEJuHloZtDxX8qmpPa Hu7aInlOk/aThuz2aTqMp6n5qzmKRnjS11kK3iZzre745i2hWafTV9KbkKUyU9qFsaVH 8AKg== X-Gm-Message-State: AOAM530R7oVsshqSce2uH10HQjS20ouOGYR1qKEszQnq4+lg7E93I3rQ OpktdEzkeMM0R/WRj/ehT1l17KgGbJk= X-Received: by 2002:a17:90a:db0f:: with SMTP id g15mr23799623pjv.5.1593551125958; Tue, 30 Jun 2020 14:05:25 -0700 (PDT) Received: from [2620:15c:17:3:4a0f:cfff:fe51:6667] ([2620:15c:17:3:4a0f:cfff:fe51:6667]) by smtp.gmail.com with ESMTPSA id h100sm3168311pjb.46.2020.06.30.14.05.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 Jun 2020 14:05:24 -0700 (PDT) Date: Tue, 30 Jun 2020 14:05:24 -0700 (PDT) From: David Rientjes X-X-Sender: rientjes@chino.kir.corp.google.com To: Peter Xu cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , John Hubbard , Michael Ellerman , Gerald Schaefer , Andrea Arcangeli , Linus Torvalds , Will Deacon Subject: Re: [PATCH v4 01/26] mm: Do page fault accounting in handle_mm_fault In-Reply-To: <20200630204504.38516-1-peterx@redhat.com> Message-ID: References: <20200630204504.38516-1-peterx@redhat.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) 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 Tue, 30 Jun 2020, Peter Xu wrote: > @@ -4408,6 +4440,34 @@ vm_fault_t handle_mm_fault(struct vm_area_struct *vma, unsigned long address, > mem_cgroup_oom_synchronize(false); > } > > + if (ret & (VM_FAULT_RETRY | VM_FAULT_ERROR)) > + return ret; > + > + /* > + * Do accounting in the common code, to avoid unnecessary > + * architecture differences or duplicated code. > + * > + * We arbitrarily make the rules be: > + * > + * - Unsuccessful faults do not count (e.g. when the address wasn't > + * valid). That includes arch_vma_access_permitted() failing above. > + * > + * So this is expressly not a "this many hardware page faults" > + * counter. Use the hw profiling for that. > + * > + * - Incomplete faults do not count (e.g. RETRY). They will only > + * count once completed. > + * > + * - The fault counts as a "major" fault when the final successful > + * fault is VM_FAULT_MAJOR, or if it was a retry (which implies that > + * we couldn't handle it immediately previously). > + * > + * - If the fault is done for GUP, regs will be NULL and no accounting > + * will be done. > + */ > + mm_account_fault(regs, address, (ret & VM_FAULT_MAJOR) || > + (flags & FAULT_FLAG_TRIED)); > + > return ret; > } > EXPORT_SYMBOL_GPL(handle_mm_fault); Just a nit, likely not important: I wonder if it would be cleaner to pass the vm_fault_t into mm_account_fault() and then do the VM_FAULT_RETRY and VM_FAULT_ERROR checks there as well as putting the comment about how accounting is handled in that function. Your comment is great.