From: Anton Blanchard <anton@ozlabs.org>
To: Matthew Wilcox <willy@infradead.org>
Cc: linux-mm@kvack.org, "Liam R. Howlett" <Liam.Howlett@oracle.com>
Subject: Re: brk1 tests the wrong thing
Date: Tue, 12 Jan 2021 07:17:28 +1100 [thread overview]
Message-ID: <20210112071728.5e2d5d6d@kryten.localdomain> (raw)
In-Reply-To: <20210111154124.GF35215@casper.infradead.org>
Hi Willy,
Thanks for this, I've merged it.
Anton
> ping
>
> On Thu, Dec 10, 2020 at 08:07:36PM +0000, Matthew Wilcox wrote:
> > Linux has this horrendously complicated anon_vma structure that you
> > don't care about, but the upshot is that after calling fork(), each
> > process that calls brk() gets a _new_ VMA created. That is, after
> > calling brk() the first time, the process address space looks like
> > this:
> >
> > 557777fab000-557777ff0000 rw-p 00000000 00:00 0
> > [heap] 557777ff0000-557777ff1000 rw-p 00000000 00:00 0
> > [heap]
> >
> > so what brk1 is actually testing is how long it takes to create &
> > destroy a new VMA. This does not match what most programs do --
> > most will call exec() which resets the anon_vma structures and
> > starts each program off with its own heap. And if you do have a
> > multi-process program which uses brk(), chances are it doesn't just
> > oscillate betwee zero and one extra pages of heap compared to its
> > parent.
> >
> > A better test starts out by allocating one page on the heap and then
> > throbs between one and two pages instead of throbbing between zero
> > and one page. That means we're actually testing expanding and
> > contracting the heap instead of creating and destroying a new heap.
> >
> > For realism, I wanted to add actually accessing the memory in the
> > new heap, but that doesn't work for the threaded case -- another
> > thread might remove the memory you just allocated while you're
> > allocating it. Threaded programs give each thread its own heap
> > anyway, so this is kind of a pointless syscall to ask about its
> > threaded scalability.
> >
> > Anyway, here's brk2.c. It is not very different from brk1.c, but
> > the performance results are quite different (actually worse by
> > about 10-15%).
> >
> >
> > #include <assert.h>
> > #include <sys/types.h>
> > #include <unistd.h>
> >
> > char *testcase_description = "brk unshared increase/decrease of one
> > page";
> >
> > void testcase(unsigned long long *iterations, unsigned long nr)
> > {
> > unsigned long page_size = getpagesize();
> > void *addr = sbrk(page_size) + page_size;
> >
> > while (1) {
> > addr += page_size;
> > assert(brk(addr) == 0);
> >
> > addr -= page_size;
> > assert(brk(addr) == 0);
> >
> > (*iterations) += 2;
> > }
> > }
> >
>
prev parent reply other threads:[~2021-01-11 20:17 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-10 20:07 Matthew Wilcox
2021-01-11 15:41 ` Matthew Wilcox
2021-01-11 20:17 ` Anton Blanchard [this message]
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=20210112071728.5e2d5d6d@kryten.localdomain \
--to=anton@ozlabs.org \
--cc=Liam.Howlett@oracle.com \
--cc=linux-mm@kvack.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