From: Peter Zijlstra <peterz@infradead.org>
To: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>,
Andy Lutomirski <luto@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
"H. Peter Anvin" <hpa@zytor.com>,
x86@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH, RFC] x86/mm/pat: Restore large pages after fragmentation
Date: Fri, 17 Apr 2020 17:47:14 +0200 [thread overview]
Message-ID: <20200417154714.GI20730@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20200416213229.19174-1-kirill.shutemov@linux.intel.com>
On Fri, Apr 17, 2020 at 12:32:29AM +0300, Kirill A. Shutemov wrote:
> +static void cpa_restore_large_pages(struct cpa_data *cpa,
> + struct list_head *pgtables)
> +{
> + unsigned long start, addr, end;
> + int i;
> +
> + start = __cpa_addr(cpa, 0);
> + end = start + PAGE_SIZE * cpa->numpages;
> +
> + for (addr = start; addr >= start && addr < end; addr += PUD_SIZE)
> + restore_large_pages(addr, pgtables);
Isn't that loop slightly broken?
Consider:
s e
|---------|---------|---------|---------|
a0 a1 a2 a3
Where s,e are @start,@end resp. and a# are the consecutive values of
@addr with PUD sized steps.
Then, since a3 is >= @end, we'll not take that iteration and we'll not
try and merge that last PUD, even though we possibly could. One fix is
to truncate @start (and with that @addr) to the beginning of the PUD.
Also, I'm afraid that with my proposal this loop needs to do PMD size
steps. In that regard your version does make some sense. But it is
indeed less efficient for small ranges.
One possible fix is to pass @start,@end into the
restore/reconstruct/collapse such that we can iterate the minimal set of
page-tables for each level.
next prev parent reply other threads:[~2020-04-17 15:47 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-16 21:32 Kirill A. Shutemov
2020-04-16 22:03 ` Dave Hansen
2020-04-16 22:12 ` Kirill A. Shutemov
2020-04-16 22:38 ` Dave Hansen
2020-04-17 0:52 ` Mika Penttilä
2020-04-17 11:42 ` Kirill A. Shutemov
2020-04-17 12:05 ` Mika Penttilä
2020-04-17 12:18 ` Peter Zijlstra
2020-04-17 14:42 ` Kirill A. Shutemov
2020-04-17 15:17 ` Peter Zijlstra
2020-04-17 15:47 ` Peter Zijlstra [this message]
2020-04-17 16:54 ` Kirill A. Shutemov
2020-04-25 11:43 ` [x86/mm/pat] ae64ac1a83: BUG:Bad_page_state_in_process kernel test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200417154714.GI20730@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox