[Bug nptl/18988] pthread wastes memory with mlockall(MCL_FUTURE)

["cvs-commit at gcc dot gnu.org" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=18988

--- Comment #1 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, master has been updated
       via  0edbf1230131dfeb03d843d2859e2104456fad80 (commit)
      from  5c3e322d3be3803636e38bcaf083fb59b3a34f0c (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=0edbf1230131dfeb03d843d2859e2104456fad80

commit 0edbf1230131dfeb03d843d2859e2104456fad80
Author: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Date:   Tue Jan 31 18:01:59 2017 -0200

    nptl: Invert the mmap/mprotect logic on allocated stacks (BZ#18988)

    Current allocate_stack logic for create stacks is to first mmap all
    the required memory with the desirable memory and then mprotect the
    guard area with PROT_NONE if required.  Although it works as expected,
    it pessimizes the allocation because it requires the kernel to actually
    increase commit charge (it counts against the available physical/swap
    memory available for the system).

    The only issue is to actually check this change since side-effects are
    really Linux specific and to actually account them it would require a
    kernel specific tests to parse the system wide information.  On the kernel
    I checked /proc/self/statm does not show any meaningful difference for
    vmm and/or rss before and after thread creation.  I could only see
    really meaningful information checking on system wide /proc/meminfo
    between thread creation: MemFree, MemAvailable, and Committed_AS shows
    large difference without the patch.  I think trying to use these
    kind of information on a testcase is fragile.

    The BZ#18988 reports shows that the commit pages are easily seen with
    mlockall (MCL_FUTURE) (with lock all pages that become mapped in the
    process) however a more straighfoward testcase shows that pthread_create
    could be faster using this patch:

    --
    static const int inner_count = 256;
    static const int outer_count = 128;

    static
    void *thread1(void *arg)
    {
      return NULL;
    }

    static
    void *sleeper(void *arg)
    {
      pthread_t ts[inner_count];
      for (int i = 0; i < inner_count; i++)
        pthread_create (&ts[i], &a, thread1, NULL);
      for (int i = 0; i < inner_count; i++)
        pthread_join (ts[i], NULL);

      return NULL;
    }

    int main(void)
    {
      pthread_attr_init(&a);
      pthread_attr_setguardsize(&a, 1<<20);
      pthread_attr_setstacksize(&a, 1134592);

      pthread_t ts[outer_count];
      for (int i = 0; i < outer_count; i++)
        pthread_create(&ts[i], &a, sleeper, NULL);
      for (int i = 0; i < outer_count; i++)
        pthread_join(ts[i], NULL);
        assert(r == 0);
      }
      return 0;
    }

    --

    On x86_64 (4.4.0-45-generic, gcc 5.4.0) running the small benchtests
    I see:

    $ time ./test

    real        0m3.647s
    user        0m0.080s
    sys 0m11.836s

    While with the patch I see:

    $ time ./test

    real        0m0.696s
    user        0m0.040s
    sys 0m1.152s

    So I added a pthread_create benchtest (thread_create) which check
    the thread creation latency.  As for the simple benchtests, I saw
    improvements in thread creation on all architectures I tested the
    change.

    Checked on x86_64-linux-gnu, i686-linux-gnu, aarch64-linux-gnu,
    arm-linux-gnueabihf, powerpc64le-linux-gnu, sparc64-linux-gnu,
    and sparcv9-linux-gnu.

        [BZ #18988]
        * benchtests/thread_create-inputs: New file.
        * benchtests/thread_create-source.c: Likewise.
        * support/xpthread_attr_setguardsize.c: Likewise.
        * support/Makefile (libsupport-routines): Add
        xpthread_attr_setguardsize object.
        * support/xthread.h: Add xpthread_attr_setguardsize prototype.
        * benchtests/Makefile (bench-pthread): Add thread_create.
        * nptl/allocatestack.c (allocate_stack): Call mmap with PROT_NONE and
        then mprotect the required area.

-----------------------------------------------------------------------

Summary of changes:
 ChangeLog                            |   15 ++++++++
 benchtests/Makefile                  |    2 +-
 benchtests/thread_create-inputs      |   14 +++++++
 benchtests/thread_create-source.c    |   58 +++++++++++++++++++++++++++++
 nptl/allocatestack.c                 |   66 +++++++++++++++++++++++++++++----
 support/Makefile                     |    1 +
 support/xpthread_attr_setguardsize.c |   26 +++++++++++++
 support/xthread.h                    |    2 +
 8 files changed, 175 insertions(+), 9 deletions(-)
 create mode 100644 benchtests/thread_create-inputs
 create mode 100644 benchtests/thread_create-source.c
 create mode 100644 support/xpthread_attr_setguardsize.c

-- 
You are receiving this mail because:
You are on the CC list for the bug.