Message ID | 20230515172608.3558391-1-yuanchu@google.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp7084403vqo; Mon, 15 May 2023 10:36:13 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5WIitsoV836Hp77ljl1M3iHQ/IveUlk24ImQx7DQTkM1uqXnHy3Vczy3LAjg5v3Ci7T1VY X-Received: by 2002:a17:90b:4b90:b0:24e:1e2e:20ea with SMTP id lr16-20020a17090b4b9000b0024e1e2e20eamr36514094pjb.42.1684172173068; Mon, 15 May 2023 10:36:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1684172173; cv=none; d=google.com; s=arc-20160816; b=aB8W+rcD0g+51N4Q/mtRAAXzQuHScUXU3pWs9WfcCXU3tYA59+xXUWDtdWRXuavHTW iv3MlsKidFI6aJrFxcteaDLMhDySgzD/iygQIlqBXjQ0rFd0znIyAgIpHoLLOC6p0S8k 8KGi+Xg+SowbLmIvolW+wyChM9Z2/7BiNxedGzz+Bxu26IUcREqYd0Nsp6Ib+ECpU54K ZS2M+ECM1fn3h53EtDjm5thLvB0CVYNGyE3EqGBNnIaakSOY53aleySyw8SeqAyddOa0 Mcx+3PZ1xkyzKnqirFud8iMcQGye+QFTRGQXe3yDZwPW9k7abdZ3fSli6rcYprUblpvR NVGw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:message-id:mime-version:date :dkim-signature; bh=y97BQ7sR2LBYQN45EWEO4FJ6RSEUfFrbQxSXtC1eEEg=; b=ozpED6f2dznIzGziWqzX7CcNHk4wQGBWsTuRFdF6BjCQmTCfRRGJkwNEn+W8LOE4z/ qmnUr9I9of+2nDPM0CmqF4CAywz5M4QLqZi88aOnTBXTLr1S8O3n2TKOuaFuLMjqE7Sq QqltJ7MCpCQyKsGf+Eo3tNbiLHPnwp2yiNrAIZ3Vb4NF89DY2y2CNFUuKfQhTL8IbOvc GfIrFZ8CMTYQmU+xneTCNPEVZZoPGorh6gTisUJ0hdx4CbmBDqo/MR8mDKmjjYMXNI5t nPMyYjyLytxCwW+ZlBlwAY6PQs2YDkHUMvYk/ndxYdVYSd0HBGHWW586+DOosutv4qGy xnXA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20221208 header.b=lnrHEXI2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id i7-20020a17090aee8700b00246a6cecff8si84937pjz.44.2023.05.15.10.36.01; Mon, 15 May 2023 10:36:13 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20221208 header.b=lnrHEXI2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 S244304AbjEOR2w (ORCPT <rfc822;peekingduck44@gmail.com> + 99 others); Mon, 15 May 2023 13:28:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49082 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244288AbjEOR1l (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 15 May 2023 13:27:41 -0400 Received: from mail-yb1-xb4a.google.com (mail-yb1-xb4a.google.com [IPv6:2607:f8b0:4864:20::b4a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A492214342 for <linux-kernel@vger.kernel.org>; Mon, 15 May 2023 10:26:26 -0700 (PDT) Received: by mail-yb1-xb4a.google.com with SMTP id 3f1490d57ef6-ba7831dfe95so4179676276.2 for <linux-kernel@vger.kernel.org>; Mon, 15 May 2023 10:26:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1684171584; x=1686763584; h=cc:to:from:subject:message-id:mime-version:date:from:to:cc:subject :date:message-id:reply-to; bh=y97BQ7sR2LBYQN45EWEO4FJ6RSEUfFrbQxSXtC1eEEg=; b=lnrHEXI214x0JOHTaG19NvuKmqNZq8vfQFKdpU6IFL5CrGuJIGS18GJfVi7BwsHwLu z/19S9vAZW30pNF09qix5IlZ31ZEXIfoGPrblHX6Enf6KFUoXTTZnWap+ULYaVY8vhtU OkCdhS24qIkQeup6yuRZj7uh7CWNtThe5UGcraCNGfBBC5Hww348MxDxRagpAxcDVTgA AZ7h+zuAXJzQAH2BNFM6Zv0fa/yUNkqKLh+ZXEOhgjyLaqTiXJhjvNH8l0R1RPrqwNd7 0RKoPgChapU4TerGr+ESr+HQzkCOntbXEi2Aj+4c6i7PG4f7i/oYDqbdgA2BE8qDfgLN /7wQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684171584; x=1686763584; h=cc:to:from:subject:message-id:mime-version:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=y97BQ7sR2LBYQN45EWEO4FJ6RSEUfFrbQxSXtC1eEEg=; b=CdBiaWx1LxX3ezy+P4iV4RdOeOG7o8BYzmmSVmxcCey7i+JFbiqfwvPOSBffudXmG/ F6BSiiGGVmGZF2e+FY+mI2qHvLISEkE24OJN386WcpXNGf8kWn/69m2Jv599hopJe9yh CTqmS3sQWkdIsICdxHoidpbaRIVlg68jqdIuKqvGKEXXTfmsNgQR16muNWUtCMkpD0R9 n6vFrv3oE+9vddW/J47MZTuiJYxcf93BvWP7DDNxEpfARklKJUuiubm7iDehOaH9y0f/ D1tH9C37zFsPQ66N47lovLFd4PFSRhmznIdGUn3oaaoyfYCgUmjJ+1wLWRVSGASwJOAk Cpcw== X-Gm-Message-State: AC+VfDyS6QIXUKfBZCMOWnjP5lDttwvp+ZVbDY5N9wezD8q+Nt26wICl 9Mc5U9H1OvO/niyoHIamZYoMvJB+Rh/q X-Received: from yuanchu.bej.corp.google.com ([2401:fa00:44:10:166c:6ee8:fb91:4744]) (user=yuanchu job=sendgmr) by 2002:a5b:750:0:b0:ba7:75a8:e37d with SMTP id s16-20020a5b0750000000b00ba775a8e37dmr3199880ybq.4.1684171584365; Mon, 15 May 2023 10:26:24 -0700 (PDT) Date: Tue, 16 May 2023 01:26:08 +0800 Mime-Version: 1.0 X-Mailer: git-send-email 2.40.1.606.ga4b1b128d6-goog Message-ID: <20230515172608.3558391-1-yuanchu@google.com> Subject: [PATCH] mm: pagemap: restrict pagewalk to the requested range From: Yuanchu Xie <yuanchu@google.com> To: Andrew Morton <akpm@linux-foundation.org> Cc: "Liam R . Howlett" <Liam.Howlett@Oracle.com>, Yang Shi <shy828301@gmail.com>, "Zach O'Keefe" <zokeefe@google.com>, Peter Xu <peterx@redhat.com>, "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>, Matthew Wilcox <willy@infradead.org>, Pasha Tatashin <pasha.tatashin@soleen.com>, Yuanchu Xie <yuanchu@google.com>, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-9.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1765982520797215509?= X-GMAIL-MSGID: =?utf-8?q?1765982520797215509?= |
Series |
mm: pagemap: restrict pagewalk to the requested range
|
|
Commit Message
Yuanchu Xie
May 15, 2023, 5:26 p.m. UTC
The pagewalk in pagemap_read reads one PTE past the end of the requested
range, and stops when the buffer runs out of space. While it produces
the right result, the extra read is unnecessary and less performant.
I timed the following command before and after this patch:
dd count=100000 if=/proc/self/pagemap of=/dev/null
The results are consistently within 0.001s across 5 runs.
Before:
100000+0 records in
100000+0 records out
51200000 bytes (51 MB) copied, 0.0763159 s, 671 MB/s
real 0m0.078s
user 0m0.012s
sys 0m0.065s
After:
100000+0 records in
100000+0 records out
51200000 bytes (51 MB) copied, 0.0487928 s, 1.0 GB/s
real 0m0.050s
user 0m0.011s
sys 0m0.039s
Signed-off-by: Yuanchu Xie <yuanchu@google.com>
---
fs/proc/task_mmu.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
Comments
On Tue, May 16, 2023 at 01:26:08AM +0800, Yuanchu Xie wrote: > The pagewalk in pagemap_read reads one PTE past the end of the requested > range, and stops when the buffer runs out of space. While it produces > the right result, the extra read is unnecessary and less performant. > > I timed the following command before and after this patch: > dd count=100000 if=/proc/self/pagemap of=/dev/null > The results are consistently within 0.001s across 5 runs. > > Before: > 100000+0 records in > 100000+0 records out > 51200000 bytes (51 MB) copied, 0.0763159 s, 671 MB/s > > real 0m0.078s > user 0m0.012s > sys 0m0.065s > > After: > 100000+0 records in > 100000+0 records out > 51200000 bytes (51 MB) copied, 0.0487928 s, 1.0 GB/s > > real 0m0.050s > user 0m0.011s > sys 0m0.039s > > Signed-off-by: Yuanchu Xie <yuanchu@google.com> Acked-by: Peter Xu <peterx@redhat.com>
On Tue, May 16, 2023 at 01:26:08AM +0800, Yuanchu Xie wrote: > The pagewalk in pagemap_read reads one PTE past the end of the requested > range, and stops when the buffer runs out of space. While it produces > the right result, the extra read is unnecessary and less performant. > > I timed the following command before and after this patch: > dd count=100000 if=/proc/self/pagemap of=/dev/null > The results are consistently within 0.001s across 5 runs. > > Before: > 100000+0 records in > 100000+0 records out > 51200000 bytes (51 MB) copied, 0.0763159 s, 671 MB/s > > real 0m0.078s > user 0m0.012s > sys 0m0.065s > > After: > 100000+0 records in > 100000+0 records out > 51200000 bytes (51 MB) copied, 0.0487928 s, 1.0 GB/s > > real 0m0.050s > user 0m0.011s > sys 0m0.039s > > Signed-off-by: Yuanchu Xie <yuanchu@google.com> Acked-by: Mike Rapoport (IBM) <rppt@kernel.org> > --- > fs/proc/task_mmu.c | 12 ++++++------ > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c > index 420510f6a545..6259dd432eeb 100644 > --- a/fs/proc/task_mmu.c > +++ b/fs/proc/task_mmu.c > @@ -1689,23 +1689,23 @@ static ssize_t pagemap_read(struct file *file, char __user *buf, > /* watch out for wraparound */ > start_vaddr = end_vaddr; > if (svpfn <= (ULONG_MAX >> PAGE_SHIFT)) { > + unsigned long end; > + > ret = mmap_read_lock_killable(mm); > if (ret) > goto out_free; > start_vaddr = untagged_addr_remote(mm, svpfn << PAGE_SHIFT); > mmap_read_unlock(mm); > + > + end = start_vaddr + ((count / PM_ENTRY_BYTES) << PAGE_SHIFT); > + if (end >= start_vaddr && end < mm->task_size) > + end_vaddr = end; > } > > /* Ensure the address is inside the task */ > if (start_vaddr > mm->task_size) > start_vaddr = end_vaddr; > > - /* > - * The odds are that this will stop walking way > - * before end_vaddr, because the length of the > - * user buffer is tracked in "pm", and the walk > - * will stop when we hit the end of the buffer. > - */ > ret = 0; > while (count && (start_vaddr < end_vaddr)) { > int len; > -- > 2.40.1.606.ga4b1b128d6-goog > >
On Mon, May 15, 2023 at 10:26 AM Yuanchu Xie <yuanchu@google.com> wrote: > > The pagewalk in pagemap_read reads one PTE past the end of the requested > range, and stops when the buffer runs out of space. While it produces > the right result, the extra read is unnecessary and less performant. > > I timed the following command before and after this patch: > dd count=100000 if=/proc/self/pagemap of=/dev/null > The results are consistently within 0.001s across 5 runs. > > Before: > 100000+0 records in > 100000+0 records out > 51200000 bytes (51 MB) copied, 0.0763159 s, 671 MB/s > > real 0m0.078s > user 0m0.012s > sys 0m0.065s > > After: > 100000+0 records in > 100000+0 records out > 51200000 bytes (51 MB) copied, 0.0487928 s, 1.0 GB/s > > real 0m0.050s > user 0m0.011s > sys 0m0.039s > > Signed-off-by: Yuanchu Xie <yuanchu@google.com> Reviewed-by: Yang Shi <shy828301@gmail.com> > --- > fs/proc/task_mmu.c | 12 ++++++------ > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c > index 420510f6a545..6259dd432eeb 100644 > --- a/fs/proc/task_mmu.c > +++ b/fs/proc/task_mmu.c > @@ -1689,23 +1689,23 @@ static ssize_t pagemap_read(struct file *file, char __user *buf, > /* watch out for wraparound */ > start_vaddr = end_vaddr; > if (svpfn <= (ULONG_MAX >> PAGE_SHIFT)) { > + unsigned long end; > + > ret = mmap_read_lock_killable(mm); > if (ret) > goto out_free; > start_vaddr = untagged_addr_remote(mm, svpfn << PAGE_SHIFT); > mmap_read_unlock(mm); > + > + end = start_vaddr + ((count / PM_ENTRY_BYTES) << PAGE_SHIFT); > + if (end >= start_vaddr && end < mm->task_size) > + end_vaddr = end; > } > > /* Ensure the address is inside the task */ > if (start_vaddr > mm->task_size) > start_vaddr = end_vaddr; > > - /* > - * The odds are that this will stop walking way > - * before end_vaddr, because the length of the > - * user buffer is tracked in "pm", and the walk > - * will stop when we hit the end of the buffer. > - */ > ret = 0; > while (count && (start_vaddr < end_vaddr)) { > int len; > -- > 2.40.1.606.ga4b1b128d6-goog >
On Tue, 16 May 2023, Yuanchu Xie wrote: > The pagewalk in pagemap_read reads one PTE past the end of the requested > range, and stops when the buffer runs out of space. While it produces > the right result, the extra read is unnecessary and less performant. > > I timed the following command before and after this patch: > dd count=100000 if=/proc/self/pagemap of=/dev/null > The results are consistently within 0.001s across 5 runs. > > Before: > 100000+0 records in > 100000+0 records out > 51200000 bytes (51 MB) copied, 0.0763159 s, 671 MB/s > > real 0m0.078s > user 0m0.012s > sys 0m0.065s > > After: > 100000+0 records in > 100000+0 records out > 51200000 bytes (51 MB) copied, 0.0487928 s, 1.0 GB/s > > real 0m0.050s > user 0m0.011s > sys 0m0.039s > > Signed-off-by: Yuanchu Xie <yuanchu@google.com> Acked-by: David Rientjes <rientjes@google.com>
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c index 420510f6a545..6259dd432eeb 100644 --- a/fs/proc/task_mmu.c +++ b/fs/proc/task_mmu.c @@ -1689,23 +1689,23 @@ static ssize_t pagemap_read(struct file *file, char __user *buf, /* watch out for wraparound */ start_vaddr = end_vaddr; if (svpfn <= (ULONG_MAX >> PAGE_SHIFT)) { + unsigned long end; + ret = mmap_read_lock_killable(mm); if (ret) goto out_free; start_vaddr = untagged_addr_remote(mm, svpfn << PAGE_SHIFT); mmap_read_unlock(mm); + + end = start_vaddr + ((count / PM_ENTRY_BYTES) << PAGE_SHIFT); + if (end >= start_vaddr && end < mm->task_size) + end_vaddr = end; } /* Ensure the address is inside the task */ if (start_vaddr > mm->task_size) start_vaddr = end_vaddr; - /* - * The odds are that this will stop walking way - * before end_vaddr, because the length of the - * user buffer is tracked in "pm", and the walk - * will stop when we hit the end of the buffer. - */ ret = 0; while (count && (start_vaddr < end_vaddr)) { int len;