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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 E1767C433E0 for ; Mon, 11 Jan 2021 20:17:43 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 146BF222B3 for ; Mon, 11 Jan 2021 20:17:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 146BF222B3 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=ozlabs.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 185976B00D0; Mon, 11 Jan 2021 15:17:42 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 138006B00D8; Mon, 11 Jan 2021 15:17:42 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F40666B00D9; Mon, 11 Jan 2021 15:17:41 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0056.hostedemail.com [216.40.44.56]) by kanga.kvack.org (Postfix) with ESMTP id DE89F6B00D0 for ; Mon, 11 Jan 2021 15:17:41 -0500 (EST) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id A679C181AC9BF for ; Mon, 11 Jan 2021 20:17:41 +0000 (UTC) X-FDA: 77694604722.29.slope01_290b1052750f Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin29.hostedemail.com (Postfix) with ESMTP id E0907180868F2 for ; Mon, 11 Jan 2021 20:17:40 +0000 (UTC) X-HE-Tag: slope01_290b1052750f X-Filterd-Recvd-Size: 4125 Received: from ozlabs.org (ozlabs.org [203.11.71.1]) by imf27.hostedemail.com (Postfix) with ESMTP for ; Mon, 11 Jan 2021 20:17:39 +0000 (UTC) Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.ozlabs.org (Postfix) with ESMTPSA id 4DF4kl09xCz9sWC; Tue, 12 Jan 2021 07:17:29 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ozlabs.org; s=201707; t=1610396255; bh=lyZwMvrLf3Nw2DcihICMMv6s2d2fxektrvcprYxrnhI=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=sn6gSIZuCsya5hgXTeesWyfLGCNsI55/OnqlTlPWt18Fp1N7RK2aIgrebdcx6hoYI BzNPeYmP2XqokZzZmxfNHIqe3YsFU0KNyMw4YCiCJa5XHavhVHdTf2Z8mtxhfjOHIy 7qh18Ka6j1+iWAvPGPNeBPpjqLDN3pPghpskAj1Gn0MbKWdJ37cGX8fdrZxKUkyPNE OzYABWg9eqwRdztEPTHwihkaZ0VtiCJnagxGAhEO52uElf+fqefdx69jYqGKHchWyJ 5tzISVNCeulCOP3eKdxOmvdD1QOCrMSIHpxV+8nPNUxBm02LtY/CnIz5gJuc3PnvDE G/8CkKDtezBNw== Date: Tue, 12 Jan 2021 07:17:28 +1100 From: Anton Blanchard To: Matthew Wilcox Cc: linux-mm@kvack.org, "Liam R. Howlett" Subject: Re: brk1 tests the wrong thing Message-ID: <20210112071728.5e2d5d6d@kryten.localdomain> In-Reply-To: <20210111154124.GF35215@casper.infradead.org> References: <20201210200736.GA7338@casper.infradead.org> <20210111154124.GF35215@casper.infradead.org> X-Mailer: Mutt/1.8.0 (2017-02-23) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Bogosity: Ham, tests=bogofilter, spamicity=0.000006, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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 > > #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; > > } > > } > > >