From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 41F32C4361B for ; Thu, 10 Dec 2020 20:07:43 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 74B3922D5A for ; Thu, 10 Dec 2020 20:07:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 74B3922D5A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id CF0D76B0036; Thu, 10 Dec 2020 15:07:41 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CA2816B005D; Thu, 10 Dec 2020 15:07:41 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B8EF06B0068; Thu, 10 Dec 2020 15:07:41 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0200.hostedemail.com [216.40.44.200]) by kanga.kvack.org (Postfix) with ESMTP id 9E7A86B0036 for ; Thu, 10 Dec 2020 15:07:41 -0500 (EST) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 58565249C for ; Thu, 10 Dec 2020 20:07:41 +0000 (UTC) X-FDA: 77578457922.26.heat19_11096a9273fb Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin26.hostedemail.com (Postfix) with ESMTP id 3061A1804B669 for ; Thu, 10 Dec 2020 20:07:41 +0000 (UTC) X-HE-Tag: heat19_11096a9273fb X-Filterd-Recvd-Size: 3458 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf42.hostedemail.com (Postfix) with ESMTP for ; Thu, 10 Dec 2020 20:07:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=Content-Type:MIME-Version:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:In-Reply-To:References; bh=TfWy+qToZRW2BS4OXrjekiuAK7++SAvdCDUzOw3eNmk=; b=ONBP2GulYn82/mxtPBmWnccSlv kcr6dHLDvPBIsbQ38XbfDRsyhFUzWC0iaoIKYPX/LMV4lgNPy4kwYveGUBYSul9UURmJHgnHXkpEk 07RbZPzFz4DcwiuouD9mtnp6ZQFRgYBnGGsVb+kTFaWM0/Jdb/C14WA94QTqARHxZFeTESq4Lj8vz dI0Xny8rUcbwJsGPyf5rTuC2LFjhZGXMBasEkbewL5al2exVs0zd7qwoM+lq9rDiznWI5D9iyTwZd YcyinCbNT8PCs567e4guq0iB7lk4lMnfhb5Xi6+SK+iDWVv8CEAu/lpbYLTGAw9P4LrbYiQFWE567 jfKghHnQ==; Received: from willy by casper.infradead.org with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1knSDw-0001LE-Ea; Thu, 10 Dec 2020 20:07:36 +0000 Date: Thu, 10 Dec 2020 20:07:36 +0000 From: Matthew Wilcox To: anton@ozlabs.org Cc: linux-mm@kvack.org, "Liam R. Howlett" Subject: brk1 tests the wrong thing Message-ID: <20201210200736.GA7338@casper.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Bogosity: Ham, tests=bogofilter, spamicity=0.004116, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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 #include #include 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; } }