linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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;
> 	}
> }
> 


  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).