From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id 03672385800B; Fri, 20 Aug 2021 12:35:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 03672385800B Received: from pps.filterd (m0098393.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 17KCYCC7032597; Fri, 20 Aug 2021 08:35:14 -0400 Received: from ppma02dal.us.ibm.com (a.bd.3ea9.ip4.static.sl-reverse.com [169.62.189.10]) by mx0a-001b2d01.pphosted.com with ESMTP id 3ahq5ehnua-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 20 Aug 2021 08:35:14 -0400 Received: from pps.filterd (ppma02dal.us.ibm.com [127.0.0.1]) by ppma02dal.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 17KCYmiH017162; Fri, 20 Aug 2021 12:35:13 GMT Received: from b01cxnp22034.gho.pok.ibm.com (b01cxnp22034.gho.pok.ibm.com [9.57.198.24]) by ppma02dal.us.ibm.com with ESMTP id 3aeey0hag8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 20 Aug 2021 12:35:12 +0000 Received: from b01ledav006.gho.pok.ibm.com (b01ledav006.gho.pok.ibm.com [9.57.199.111]) by b01cxnp22034.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 17KCYUHo11534776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 20 Aug 2021 12:34:30 GMT Received: from b01ledav006.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 40E0CAC060; Fri, 20 Aug 2021 12:34:30 +0000 (GMT) Received: from b01ledav006.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A0A55AC05B; Fri, 20 Aug 2021 12:34:28 +0000 (GMT) Received: from TP480.linux.ibm.com (unknown [9.160.146.230]) by b01ledav006.gho.pok.ibm.com (Postfix) with ESMTP; Fri, 20 Aug 2021 12:34:28 +0000 (GMT) References: <20210818142000.128752-1-adhemerval.zanella@linaro.org> <20210818142000.128752-5-adhemerval.zanella@linaro.org> <871r6pjp03.fsf@linux.ibm.com> <6c46a3ab-3031-5729-6160-d13cca1899cb@linaro.org> User-agent: mu4e 1.4.10; emacs 27.2 From: Matheus Castanho To: Adhemerval Zanella Cc: Norbert Manthey , Guillaume Morin , Siddhesh Poyarekar , libc-alpha@sourceware.org, Tulio Magno Quites Machado Filho Subject: Re: [PATCH v2 4/4] malloc: Add Huge Page support for sysmalloc Message-ID: <87y28wiata.fsf@linux.ibm.com> In-reply-to: <6c46a3ab-3031-5729-6160-d13cca1899cb@linaro.org> Date: Fri, 20 Aug 2021 09:34:27 -0300 MIME-Version: 1.0 Content-Type: text/plain X-TM-AS-GCONF: 00 X-Proofpoint-GUID: Zw6mjapjcG6ftdrJAHNw7JzjXicncDag X-Proofpoint-ORIG-GUID: Zw6mjapjcG6ftdrJAHNw7JzjXicncDag X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-08-20_03:2021-08-20, 2021-08-20 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 malwarescore=0 bulkscore=0 clxscore=1015 phishscore=0 priorityscore=1501 mlxlogscore=999 impostorscore=0 adultscore=0 suspectscore=0 spamscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2107140000 definitions=main-2108200070 X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2021 12:35:35 -0000 Adhemerval Zanella writes: > On 19/08/2021 14:58, Matheus Castanho wrote: >> Hi Adhemerval, >> >> I tested this patchset on a POWER9, and I'm seeing the following test >> failures when running make check with glibc.malloc.mmap_hugetlb=1: > > Thanks for checking on this. > >> >> malloc/tst-free-errno >> malloc/tst-free-errno-malloc-check >> malloc/tst-free-errno-mcheck > > These one I couldn't really reproduce it on gcc farm power machines, > a power9 with 2M huge page default and power8 with 16M default. Both > didn't have any page allocated in the poll. I don't have admin access > so I can change the pool size to check what is happening. > > I also tested on my x86_64 environment without any pages in the poll, > with 4 pages in the pool and with 10 pages. > I confirm that without pages in the pool the tests pass correctly. Only when I add them to the pool things start failing. In this case I'm reserving 500 16 MB pages: $ grep -i hugepages /proc/meminfo AnonHugePages: 0 kB ShmemHugePages: 0 kB FileHugePages: 0 kB HugePages_Total: 500 HugePages_Free: 500 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 16384 kB > If you could the stacktrace from where we get the > "Didn't expect signal from child: got `Aborted'" it would be useful. > This is what GDB is showing me when the abort happens: #0 0x00007ffff7dccf00 in __pthread_kill_internal (threadid=, signo=) at pthread_kill.c:44 #1 0x00007ffff7d6e26c in __GI_raise (sig=) at ../sysdeps/posix/raise.c:26 #2 0x00007ffff7d50490 in __GI_abort () at abort.c:79 #3 0x00007ffff7dba770 in __libc_message (action=, fmt=) at ../sysdeps/posix/libc_fatal.c:155 #4 0x00007ffff7ddc4e8 in malloc_printerr (str=, str@entry=0x7ffff7efdc90 "double free or corruption (out)") at malloc.c:5654 #5 0x00007ffff7ddefe8 in _int_free (av=0x7ffff7f60e30 , p=0x7ffff80203d0, have_lock=, have_lock@entry=0) at malloc.c:4555 #6 0x00007ffff7de2160 in __GI___libc_free (mem=) at malloc.c:3358 #7 0x0000000010001ee4 in do_test () at tst-free-errno.c:123 #8 0x0000000010002730 in run_test_function (argc=argc@entry=1, argv=argv@entry=0x7fffffffede0, config=config@entry=0x7fffffffe950) at support_test_main.c:232 #9 0x00000000100032fc in support_test_main (argc=1, argv=0x7fffffffede0, config=0x7fffffffe950) at support_test_main.c:431 #10 0x00000000100019d0 in main (argc=, argv=) at ../support/test-driver.c:168 #11 0x00007ffff7d50818 in __libc_start_call_main (main=main@entry=0x10001980
, argc=argc@entry=1, argv=argv@entry=0x7fffffffede0, auxvec=auxvec@entry=0x7fffffffef68) at ../sysdeps/nptl/libc_start_call_main.h:58 #12 0x00007ffff7d50a00 in generic_start_main (fini=, stack_end=, rtld_fini=, init=, auxvec=, argv=, argc=, main=) at ../csu/libc-start.c:409 #13 __libc_start_main_impl (argc=1, argv=0x7fffffffede0, ev=, auxvec=0x7fffffffef68, rtld_fini=, stinfo=, stack_on_entry=) at ../sysdeps/unix/sysv/linux/powerpc/libc-start.c:98 #14 0x0000000000000000 in ?? () > It could be also something related to /proc/sys/vm/max_map_count > value, since it mmap seems to be failing for some reason. > This is what the machine I'm using now has: $ cat /proc/sys/vm/max_map_count 65530 >> posix/tst-exec >> posix/tst-exec-static >> posix/tst-spawn >> posix/tst-spawn-static >> posix/tst-spawn5 > > These are an overlook at 'malloc_default_hugepage_size()' where it > does not close the file descriptor on success. I have fixed it. Ok, thanks! -- Matheus Castanho