From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <freeman.zhang1992@gmail.com>
Received: from mail-il1-x132.google.com (mail-il1-x132.google.com
 [IPv6:2607:f8b0:4864:20::132])
 by sourceware.org (Postfix) with ESMTPS id EB21E3861828
 for <libc-help@sourceware.org>; Tue, 30 Mar 2021 14:20:21 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org EB21E3861828
Received: by mail-il1-x132.google.com with SMTP id d2so14276349ilm.10
 for <libc-help@sourceware.org>; Tue, 30 Mar 2021 07:20:21 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:from:date:message-id:subject:to
 :content-transfer-encoding;
 bh=qt1W+s7yJEtxfw3o+iB01PV7yfIkYDrtM8FSxF/F2i0=;
 b=cyahdhmHr2tUo4c6hwsPmjKJGYJEW6j9xUWHo5JkgvoCt3w9KcOVvfJEKA2oyaw0D9
 FSYdyOVzykjPHjNTEOlVGR96wFO2mjA2tcZ535f1JBBnVoSOpT2vfx6UbX9lvAG2dcZ8
 QWSeCXLbSX/9//LhzAXNGZL9RquWfwmJBLsEZcif1cbcsD3EvY9JlXkUsr/YDhSPSZ8T
 DraW/JTLlMqP0p3PesZoU35V5WwGmQCexrTx0D1TA2L5aV4ehhIZwizDAng//ykOrT9n
 a9IKnwsmRzZOvLHwu/G0UMW0HB7Xzm5bnDF/2pZdod38ls5jf0ICcVZuNogdH3yJLbaY
 +2Sw==
X-Gm-Message-State: AOAM530LRbdrJ9Y2wY9WXdbp1c52V8pBBVj9BG4e9qiiQ+81u9ZzDbKU
 ibj4lK87RHkEXdbkjJzQa8RyjNXmnEDX3PgkblqSjjdRhsbJ/Q==
X-Google-Smtp-Source: ABdhPJzyNH/GPoeWsAHZ4vIZ6vSsOgntIicx2WnbjLMcVohD+DFnFDhF0nEsjmhVInGmalxSgaBJGJAAbb5rBywAYzA=
X-Received: by 2002:a05:6e02:20ee:: with SMTP id
 q14mr24505057ilv.223.1617114021215; 
 Tue, 30 Mar 2021 07:20:21 -0700 (PDT)
MIME-Version: 1.0
From: Zhengyu Zhang <freeman.zhang1992@gmail.com>
Date: Tue, 30 Mar 2021 22:20:10 +0800
Message-ID: <CAOYRFkkTyr1qeA4Kdb7+nd=B0N3u-nz+DEfcEbmhWhk5deuFig@mail.gmail.com>
Subject: mmap&munmap syscall and malloc&free function call mismatch
To: libc-help@sourceware.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00, DKIM_SIGNED,
 DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_ENVFROM_END_DIGIT,
 FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS,
 TXREP autolearn=ham autolearn_force=no version=3.4.2
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on
 server2.sourceware.org
X-BeenThere: libc-help@sourceware.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Libc-help mailing list <libc-help.sourceware.org>
List-Unsubscribe: <https://sourceware.org/mailman/options/libc-help>,
 <mailto:libc-help-request@sourceware.org?subject=unsubscribe>
List-Archive: <https://sourceware.org/pipermail/libc-help/>
List-Help: <mailto:libc-help-request@sourceware.org?subject=help>
List-Subscribe: <https://sourceware.org/mailman/listinfo/libc-help>,
 <mailto:libc-help-request@sourceware.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Mar 2021 14:20:23 -0000

Hi list!

As I run the code shown below, mmap&munmap syscall doesn=E2=80=99t match
malloc&free in some cases.

```
// g++ test_memcpy.c -std=3Dc++11 -lpthread -O0
#include <stdlib.h>
#include <stdio.h>
#include <malloc.h>
#include <string.h>
#include <unistd.h>
#include <thread>
#include <iostream>

#define THREAD_NUM 40

void foo()
{
        char *src_buf =3D (char *)malloc(256*1024);
        char *dst_buf =3D NULL;
        long loop =3D 80000;
        memset(src_buf, 1, 256*1024);
        while (--loop) {
                posix_memalign((void**)&dst_buf, 4096, 256 * 1024);
                memcpy(dst_buf, src_buf, 256 * 1024);
                free(dst_buf);
                //usleep(100);
        }
}

int main() {
    int i =3D 0;
    std::thread *t[THREAD_NUM];
    for (i =3D 0; i < THREAD_NUM; ++i)
        t[i] =3D new std::thread(foo);

    for (i =3D 0; i < THREAD_NUM; ++i)
        t[i]->join();
    return 0;
}
```
The binary is linked against glibc 2.17.

When THREAD_NUM=3D4, strace results show mmap is called 320,000 times,
as expected (4 * 80,000)
When THREAD_NUM=3D40, mmap is only called about 430,0000 times. I am
expecting 3,200,000 (40 * 80,000)
Then I add `usleep(100)` in the loop, it becomes 3,200,000 as expected.

I do not know how to explain this. Since I investigate the glibc
malloc code, free() will munmap the mmapped memory immediately so
there should be no chance for caching stuff to save syscall.

So how can mmap&munmap be less than malloc&free?


All the best!
Zhengyu