From: Matthew Wilcox <willy@infradead.org>
To: anton@ozlabs.org
Cc: linux-mm@kvack.org, "Liam R. Howlett" <Liam.Howlett@oracle.com>
Subject: Re: brk1 tests the wrong thing
Date: Mon, 11 Jan 2021 15:41:24 +0000 [thread overview]
Message-ID: <20210111154124.GF35215@casper.infradead.org> (raw)
In-Reply-To: <20201210200736.GA7338@casper.infradead.org>
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;
> }
> }
>
next prev parent reply other threads:[~2021-01-11 15:41 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-10 20:07 brk1 tests the wrong thing Matthew Wilcox
2021-01-11 15:41 ` Matthew Wilcox [this message]
2021-01-11 20:17 ` Anton Blanchard
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=20210111154124.GF35215@casper.infradead.org \
--to=willy@infradead.org \
--cc=Liam.Howlett@oracle.com \
--cc=anton@ozlabs.org \
--cc=linux-mm@kvack.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;
as well as URLs for NNTP newsgroup(s).