From: Matthew Wilcox <willy@infradead.org>
To: anton@ozlabs.org
Cc: linux-mm@kvack.org, "Liam R. Howlett" <Liam.Howlett@oracle.com>
Subject: brk1 tests the wrong thing
Date: Thu, 10 Dec 2020 20:07:36 +0000 [thread overview]
Message-ID: <20201210200736.GA7338@casper.infradead.org> (raw)
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 reply other threads:[~2020-12-10 20:07 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-10 20:07 Matthew Wilcox [this message]
2021-01-11 15:41 ` brk1 tests the wrong thing Matthew Wilcox
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=20201210200736.GA7338@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).