From: lizhe.67@bytedance.com
To: willy@infradead.org
Cc: akpm@linux-foundation.org, boqun.feng@gmail.com,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
lizhe.67@bytedance.com, longman@redhat.com, mingo@redhat.com,
peterz@infradead.org, will@kernel.org
Subject: Re: [RFC 2/2] khugepaged: use upgrade_read() to optimize collapse_huge_page
Date: Fri, 18 Oct 2024 14:37:12 +0800 [thread overview]
Message-ID: <20241018063712.44028-1-lizhe.67@bytedance.com> (raw)
In-Reply-To: <ZxEPDMUnYlAy3r3_@casper.infradead.org>
On Thu, 17 Oct 2024 14:20:12 +0100, willy@infradead.org wrote:
> On Thu, Oct 17, 2024 at 02:18:41PM +0800, lizhe.67@bytedance.com wrote:
> > On Wed, 16 Oct 2024 12:53:15 +0100, willy@infradead.org wrote:
> >
> > >On Wed, Oct 16, 2024 at 12:36:00PM +0800, lizhe.67@bytedance.com wrote:
> > >> From: Li Zhe <lizhe.67@bytedance.com>
> > >>
> > >> In function collapse_huge_page(), we drop mmap read lock and get
> > >> mmap write lock to prevent most accesses to pagetables. There is
> > >> a small time window to allow other tasks to acquire the mmap lock.
> > >> With the use of upgrade_read(), we don't need to check vma and pmd
> > >> again in most cases.
> > >
> > >This is clearly a performance optimisation. So you must have some
> > >numebrs that justify this, please include them.
> >
> > Yes, I will add the relevant data to v2 patch.
>
> How about telling us all now so we know whether to continue discussing
> this?
In my test environment, function collapse_huge_page() only achieved a 0.25%
performance improvement. I use ftrace to get the execution time of
collapse_huge_page(). The test code and test command are as follows.
(1) Test result:
average execution time of collapse_huge_page()
before this patch: 1611.06283 us
after this patch: 1597.01474 us
(2) Test code:
#define MMAP_SIZE (2ul*1024*1024)
#define ALIGN(x, mask) (((x) + ((mask)-1)) & ~((mask)-1))
int main(void)
{
int num = 100;
size_t page_sz = getpagesize();
while (num--) {
size_t index;
unsigned char *p_map;
unsigned char *p_map_real;
p_map = (unsigned char *)mmap(0, 2 * MMAP_SIZE, PROT_READ | PROT_WRITE, MAP_PRIVATE|MAP_ANON, -1, 0);
if (p_map == MAP_FAILED) {
printf("mmap fail\n");
return -1;
} else {
p_map_real = (char *)ALIGN((unsigned long)p_map, MMAP_SIZE);
printf("mmap get %p, align to %p\n", p_map, p_map_real);
}
for(index = 0; index < MMAP_SIZE; index += page_sz)
p_map_real[index] = 6;
int ret = madvise(p_map_real, MMAP_SIZE, 25);
printf("ret is %d\n", ret);
munmap(p_map, 2 * MMAP_SIZE);
}
return 0;
}
(3) Test command:
echo never > /sys/kernel/mm/transparent_hugepage/enabled
gcc test.c -o test
trace-cmd record -p function_graph -g collapse_huge_page --max-graph-depth 1 ./test
The optimization of the function collapse_huge_page() seems insignificant.
I am not sure whether it will have a more obvious optimization effect in
other scenarios.
next prev parent reply other threads:[~2024-10-18 6:37 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-16 4:35 [RFC 0/2] rwsem: introduce upgrade_read interface lizhe.67
2024-10-16 4:35 ` [RFC 1/2] " lizhe.67
2024-10-16 4:56 ` Christoph Hellwig
2024-10-16 7:33 ` lizhe.67
2024-10-16 7:36 ` Christoph Hellwig
2024-10-16 8:00 ` lizhe.67
2024-10-16 8:03 ` Christoph Hellwig
2024-10-16 8:13 ` lizhe.67
2024-10-16 11:51 ` Matthew Wilcox
2024-10-16 12:21 ` Christoph Hellwig
2024-10-16 11:49 ` Matthew Wilcox
2024-10-17 6:23 ` lizhe.67
2024-10-16 14:23 ` Waiman Long
2024-10-16 18:05 ` Matthew Wilcox
2024-10-16 18:39 ` Waiman Long
2024-10-17 6:46 ` lizhe.67
2024-10-17 15:05 ` Christoph Hellwig
2024-10-17 17:36 ` Waiman Long
2024-10-18 5:06 ` Christoph Hellwig
2024-10-16 4:36 ` [RFC 2/2] khugepaged: use upgrade_read() to optimize collapse_huge_page lizhe.67
2024-10-16 11:53 ` Matthew Wilcox
2024-10-17 6:18 ` lizhe.67
2024-10-17 13:20 ` Matthew Wilcox
2024-10-18 6:37 ` lizhe.67 [this message]
2024-10-23 7:27 ` kernel test robot
2024-10-16 8:09 ` [RFC 0/2] rwsem: introduce upgrade_read interface Peter Zijlstra
2024-10-16 8:53 ` lizhe.67
2024-10-16 12:10 ` Peter Zijlstra
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=20241018063712.44028-1-lizhe.67@bytedance.com \
--to=lizhe.67@bytedance.com \
--cc=akpm@linux-foundation.org \
--cc=boqun.feng@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=longman@redhat.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=will@kernel.org \
--cc=willy@infradead.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