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=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,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 D0825C433E0 for ; Wed, 24 Jun 2020 20:34:21 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 95B0220836 for ; Wed, 24 Jun 2020 20:34:21 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="NNU6JS/x" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 95B0220836 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 1166F6B0027; Wed, 24 Jun 2020 16:34:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0C7C56B0028; Wed, 24 Jun 2020 16:34:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EA88E6B0029; Wed, 24 Jun 2020 16:34:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0194.hostedemail.com [216.40.44.194]) by kanga.kvack.org (Postfix) with ESMTP id D0CB26B0027 for ; Wed, 24 Jun 2020 16:34:20 -0400 (EDT) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 2FEEB180AD830 for ; Wed, 24 Jun 2020 20:34:20 +0000 (UTC) X-FDA: 76965257880.26.farm01_3b0119326e47 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin26.hostedemail.com (Postfix) with ESMTP id 0A9161804B667 for ; Wed, 24 Jun 2020 20:34:20 +0000 (UTC) X-HE-Tag: farm01_3b0119326e47 X-Filterd-Recvd-Size: 6316 Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.61]) by imf37.hostedemail.com (Postfix) with ESMTP for ; Wed, 24 Jun 2020 20:34:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1593030858; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=778N0YMcrWGuAWTtdx98/Vr/9f1rp+JvrngLnU6hHko=; b=NNU6JS/xD9X5jbuOXnq+Ld4bDN5seEtLu/xgrvctD20XGP0nGZU81BuVcyAAwZHynlkyia zXISI2wVnNoBaB/Rwwfofd35EKg7jnr9qLH8t0ZYjm7ubYTtB6Wg5QuYjqmrOpknbWM5vd NLy4MmcisVGI/OZcoEwXLD66l4yWgSM= Received: from mail-qt1-f199.google.com (mail-qt1-f199.google.com [209.85.160.199]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-180-IZjMptn4MRKjX1xH0vRW3g-1; Wed, 24 Jun 2020 16:34:16 -0400 X-MC-Unique: IZjMptn4MRKjX1xH0vRW3g-1 Received: by mail-qt1-f199.google.com with SMTP id x6so2454554qtq.1 for ; Wed, 24 Jun 2020 13:34:16 -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=778N0YMcrWGuAWTtdx98/Vr/9f1rp+JvrngLnU6hHko=; b=TrRYavxDsOfsK+Td+QwI6cqlB41Wq5XJj3yaM8bbp1Csvc3Lv/4unYgAAVsVAfpwQY Bup0r+oxdoHlL0bRBwiYciGrIL7qH94n3KO1ydAjt5KM9B+MQv4TYpcgspePEBvhViTp MxR46VWT6WekU7P731ZED7rAA1v+pl0M12jV6sTYV+OYbwJG0qVPCsDBROmX1kMFr8Xw j2uXAYbl8gpQ/XSO7jqpd8d+qiBEVgRvjAvuw/gLmxmSPKa3llp9h+dg2ShJWOiDL0vS PIgTaAwQG7z/bUoxV35Zg/xprEqBWk/6CFwq1o+0dze+rX/D4z7WhoUQLl9jc6iKDdBZ DQ/w== X-Gm-Message-State: AOAM530uwgc5DTYYhsnhURfp/DRKAOmK95NbDwgQj//uUdAc+QQJ52XB el+tpcbmMQWeopLmQs8RQZVx4Z51IsKidzn48arrprTlUkixhT/+RL5UX/xsFgnvexX2sQPF+4/ ADfHqqTbbQvs= X-Received: by 2002:a37:43cb:: with SMTP id q194mr27321569qka.154.1593030856270; Wed, 24 Jun 2020 13:34:16 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzNXQ5NY+YbSA74fgnqtSQv3vnfiyEXo0+8mMyoZWuHcrsoUvzY+Sy8ucVTe+W675Myu5adnA== X-Received: by 2002:a37:43cb:: with SMTP id q194mr27321541qka.154.1593030855957; Wed, 24 Jun 2020 13:34:15 -0700 (PDT) Received: from xz-x1 ([2607:9880:19c0:32::2]) by smtp.gmail.com with ESMTPSA id d78sm4032465qkg.106.2020.06.24.13.34.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Jun 2020 13:34:14 -0700 (PDT) Date: Wed, 24 Jun 2020 16:34:12 -0400 From: Peter Xu To: Gerald Schaefer Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andrew Morton , Andrea Arcangeli , Will Deacon , Michael Ellerman , Linus Torvalds Subject: Re: [PATCH 01/26] mm: Do page fault accounting in handle_mm_fault Message-ID: <20200624203412.GB64004@xz-x1> References: <20200619160538.8641-1-peterx@redhat.com> <20200619160538.8641-2-peterx@redhat.com> <20200624204903.097a5a58@thinkpad> MIME-Version: 1.0 In-Reply-To: <20200624204903.097a5a58@thinkpad> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Rspamd-Queue-Id: 0A9161804B667 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam05 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 Wed, Jun 24, 2020 at 08:49:03PM +0200, Gerald Schaefer wrote: > On Fri, 19 Jun 2020 12:05:13 -0400 > Peter Xu wrote: > > [...] > > > @@ -4393,6 +4425,38 @@ vm_fault_t handle_mm_fault(struct vm_area_struct *vma, unsigned long address, > > mem_cgroup_oom_synchronize(false); > > } > > > > + if (ret & VM_FAULT_RETRY) > > + return ret; > > I'm wondering if this also needs a check and exit for VM_FAULT_ERROR. > In arch code (s390 and all others I briefly checked), the accounting > was skipped for VM_FAULT_ERROR case. Yes. I didn't explicitly add the check because I thought it's still OK to count the error cases, especially after we've discussed about PERF_COUNT_SW_PAGE_FAULTS in v1. So far, the major reason (iiuc) to have PERF_COUNT_SW_PAGE_FAULTS still in per-arch handlers is to also cover these corner cases like VM_FAULT_ERROR. So to me it makes sense too to also count them in here. But I agree it changes the old counting on most archs. Again, I don't have strong opinion either on this, just like the same to PERF_COUNT_SW_PAGE_FAULTS... But if no one disagree, I will change this to: if (ret & (VM_FAULT_RETRY | VM_FAULT_ERROR)) return ret; So we try our best to follow the past. Btw, note that there will still be some even more special corner cases. E.g., for ARM64 it's also not accounted for some ARM64 specific fault errors (VM_FAULT_BADMAP, VM_FAULT_BADACCESS). So even if we don't count VM_FAULT_ERROR, we might still count these for ARM64. We can try to redefine VM_FAULT_ERROR in ARM64 to cover all the arch-specific errors, however that seems an overkill to me sololy for fault accountings, so hopefully I can ignore that difference. > > > + > > + /* > > + * Do accounting in the common code, to avoid unnecessary > > + * architecture differences or duplicated code. > > + * > > + * We arbitrarily make the rules be: > > + * > > + * - faults that never even got here (because the address > > + * wasn't valid). That includes arch_vma_access_permitted() > > Missing "do not count" at the end of the first sentence? > > > + * failing above. > > + * > > + * So this is expressly not a "this many hardware page > > + * faults" counter. Use the hw profiling for that. > > + * > > + * - incomplete faults (ie RETRY) do not count (see above). > > + * 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 wil be NULL and > > wil -> will Will fix both places. Thanks, -- Peter Xu