public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
From: Yang Xu <xuyang2018.jy@cn.fujitsu.com>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH v1 2/3] syscalls/mallinfo02: Add a basic test to check use mmap or sbrk
Date: Wed, 3 Feb 2021 17:47:43 +0800	[thread overview]
Message-ID: <601A713F.7020301@cn.fujitsu.com> (raw)
In-Reply-To: <YBLaQvt2g3z8Xy1A@yuki.lan>

Hi Cyril
> Hi!
>> "The number of bytes in blocks currently allocated using mmap(2).".
>> For allocations greater than or equal to 128K and that can't be satisfied from
>> the free list, the memory-allocation functions employ mmap(2) instead of increasing
>> the program break using sbrk(2).
>>
>> In this case, we test 20k size to use sbrk and 128k size to use mmap.
>
> The size when glibc uses mmap() instead of heap is libc implementation
> detail. I'm not sure that we want to have that value hardcoded in a LTP test.
Here has some wrong description, I use "MAX(info.fordblks, 131072) + 
reuse_size" size to test instead of 128K.
>
> Also glibc documentation says:
>
> The default value is set to `131072' bytes and the threshold is adjusted
> dynamically to suit the allocation patterns of the program.

IMO, the threshold is adjusted dynamically because of two things if we 
don't use mallopt with  M_MMAP_THRESHOLD
1) fordblks;  /* Total free space (bytes) */
2) the previous mmap regin space


 From mallopt man-page for  M_MMAP_THRESHOLD option, it said
" For allocations greater  than  or  equal  to  the  limit  specified 
(in  bytes)  by M_MMAP_THRESHOLD  that  can't be satisfied from the free 
list, the memory-allocation functions employ mmap(2) instead of 
increasing the program break using sbrk(2)."

So I use this code "MAX(info.fordblks, 131072)" to get the right value 
to trigger mmap.

mallopt man-page for  M_MMAP_THRESHOLD option also said "On  the
  other hand, there are some disadvantages to the use of mmap(2): 
deallocated space is not placed on the free list for reuse by later 
allocations; " .

I guess it means mmap area  is not counted int info.fordblks(free list ) 
and can be used for the next sbrk(increase the heap). That is why I add 
reuse_size when I get the corrcet mmap size. Or, I miss something?

If we can't ensure it , I will remove this patch. Or, other advise?


Best Regards
Yang Xu

>




  reply	other threads:[~2021-02-03  9:47 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-26  9:55 [LTP] [PATCH v1 1/3] syscalls/mallinfo01: Add a basic test for mallinfo Yang Xu
2021-01-26  9:55 ` [LTP] [PATCH v1 2/3] syscalls/mallinfo02: Add a basic test to check use mmap or sbrk Yang Xu
2021-01-28 15:37   ` Cyril Hrubis
2021-02-03  9:47     ` Yang Xu [this message]
2021-02-03 10:46       ` Yang Xu
2021-02-04  6:08       ` Li Wang
2021-02-04  9:53         ` Yang Xu
2021-01-26  9:55 ` [LTP] [PATCH v1 3/3] syscalls/mallinfo03: Add an overflow test when setting 2G size Yang Xu
2021-01-28 15:42   ` Cyril Hrubis
2021-02-03  9:49     ` Yang Xu
2021-02-04  8:54   ` Li Wang
2021-02-04 10:01     ` Yang Xu
2021-02-04 13:56       ` Li Wang
2021-02-04 12:12     ` [LTP] [PATCH v2 1/5] tst_mallinfo.c: Add a common print helper for mallinfo Yang Xu
2021-02-04 12:12       ` [LTP] [PATCH v2 2/5] syscalls/mallopt01: Use tst_print_mallinfo api Yang Xu
2021-02-04 12:12       ` [LTP] [PATCH v2 3/5] syscalls/mallinfo01: Add a basic test for mallinfo Yang Xu
2021-02-04 12:12       ` [LTP] [PATCH v2 4/5] syscalls/mallinfo02: Add a basic test to check use mmap or sbrk Yang Xu
2021-02-04 13:51         ` Li Wang
2021-02-05  7:51           ` Yang Xu
2021-02-05  8:15           ` Yang Xu
2021-02-05  9:00           ` Yang Xu
2021-02-05  9:20             ` Li Wang
2021-02-04 12:12       ` [LTP] [PATCH v2 5/5] syscalls/mallinfo03: Add an overflow test when setting 2G size Yang Xu
2021-02-04 13:29       ` [LTP] [PATCH v2 1/5] tst_mallinfo.c: Add a common print helper for mallinfo Li Wang
2021-02-05  7:44         ` Yang Xu
2021-02-05  8:00           ` Li Wang
2021-02-05 11:21             ` Petr Vorel
2021-02-08 15:30             ` Cyril Hrubis
2021-02-18  5:52               ` [LTP] [PATCH v3 1/4] syscalls/mallinfo01: Add a basic test " Yang Xu
2021-02-18  5:52                 ` [LTP] [PATCH v3 2/4] syscalls/mallopt01: Use unified print_mallinfo api Yang Xu
2021-02-18  5:52                 ` [LTP] [PATCH v3 3/4] syscalls/mallinfo02: Add a basic test to check use mmap or sbrk Yang Xu
2021-02-22  6:32                   ` Li Wang
2021-02-22  6:40                     ` Yang Xu
2021-02-23  1:45                     ` Yang Xu
2021-02-18  5:52                 ` [LTP] [PATCH v3 4/4] syscalls/mallinfo03: Add an overflow test when setting 2G size Yang Xu
2021-01-28 15:50 ` [LTP] [PATCH v1 1/3] syscalls/mallinfo01: Add a basic test for mallinfo Cyril Hrubis
2021-02-03  6:03   ` Yang Xu
2021-02-04  6:42 ` Li Wang
2021-02-04  9:54   ` Yang Xu

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=601A713F.7020301@cn.fujitsu.com \
    --to=xuyang2018.jy@cn.fujitsu.com \
    --cc=ltp@lists.linux.it \
    /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