From patchwork Sat Dec 4 04:58:47 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Rongwei Wang X-Patchwork-Id: 48488 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id BEF913858427 for ; Sat, 4 Dec 2021 04:59:29 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BEF913858427 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1638593969; bh=lSrm/iofh3NG9fvCtbMDzyIfNakqWeccj+UKboQfnCY=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:Cc:From; b=eJnlteSfgHQ98Pa/27BMypHTxvy/d2lH6zTjWmPSGxjVVnq0V+s0lOXmYHKGBNPwz g/koZnu3Cq4VLT9Z7JPNak47J7bTR0SMcgEgs3EyMrJjzjmAJnvJMZQQ/PTfMvajjN j93CVXwGUickoRyHJe4gm6xhpyRxPNNcLwJbAMes= X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from out30-42.freemail.mail.aliyun.com (out30-42.freemail.mail.aliyun.com [115.124.30.42]) by sourceware.org (Postfix) with ESMTPS id 13B593858405 for ; Sat, 4 Dec 2021 04:58:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 13B593858405 X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R151e4; CH=green; DM=||false|; DS=||; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e01e04357; MF=rongwei.wang@linux.alibaba.com; NM=1; PH=DS; RN=3; SR=0; TI=SMTPD_---0UzKumWs_1638593929; Received: from localhost.localdomain(mailfrom:rongwei.wang@linux.alibaba.com fp:SMTPD_---0UzKumWs_1638593929) by smtp.aliyun-inc.com(127.0.0.1); Sat, 04 Dec 2021 12:58:50 +0800 To: libc-alpha@sourceware.org Subject: [PATCH RFC 0/1] make ld.so map .text LOAD ssegments and aligned by p_align Date: Sat, 4 Dec 2021 12:58:47 +0800 Message-Id: <20211204045848.71105-1-rongwei.wang@linux.alibaba.com> X-Mailer: git-send-email 2.32.0 MIME-Version: 1.0 X-Spam-Status: No, score=-11.5 required=5.0 tests=BAYES_00, ENV_AND_HDR_SPF_MATCH, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, UNPARSEABLE_RELAY, USER_IN_DEF_SPF_WL 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-Patchwork-Original-From: Rongwei Wang via Libc-alpha From: Rongwei Wang Reply-To: Rongwei Wang Cc: xuyu@linux.alibaba.com, gavin.dg@linux.alibaba.com Errors-To: libc-alpha-bounces+patchwork=sourceware.org@sourceware.org Sender: "Libc-alpha" Hello, Glibc Maintainers and Developers: We are software development engineers from Alibaba Cloud OS team. We are mainly responsible for the development and maintenance of Alibaba Cloud Linux. This is our first time to send patch to glibc mail-list, if we ignore anything in this patch, please let me know. Thanks very much! Recently, we try to realize the feature that make .text and .data application segments use huge pages (2M). At first, we had realized the feature in kernel, refer to LINK[1]. But the part that align the mapping address of LOAD segment was regarded as hack way, if realized in kernel. If .text wants to use huge pages, alignment of mapping address is necessary. It refers to the first LOAD segment here. So, we think it would be better to realize this part in glibc than kernel. Actually, related discussion had been proposed in LINK[2, 3]. The implementation method in Patch 1/1 just need ld a simple support, then application can call 'madvise' to mark .text pages and collapse they into huge pages by 'khugepaged' thread. (And We make a plan to provide a global sysfs inteface in OS for .text hugepages, realizing transparent .text hugepages. If you have an interested in this, a simple code works well in LINK[1].) What's more, we can see LINK[3] had mentioned .data and .text segment using huge pages. In our patch, we just realizes the .text part (first LOAD segment) and we think it's not necessary for .data segments to use huge pages because of small and no performance benefit in most applications. This patch mainly move the part that aligns the mapping address into ld.so. And the rest that realizes huge pages of the .text is handed over to OS. LINK: [1] first patch in linux kernel: https://patchwork.kernel.org/project/linux-mm/cover/20211009092658.59665-1-rongwei.wang@linux.alibaba.com/ [2] https://libc-alpha.sourceware.narkive.com/zqNSW0dY/glibc-loading-of-shared-objects-with-holes-wastes-address-space [3] https://sourceware.org/pipermail/libc-alpha/2021-February/122331.html Best regards, Rongwei Wang Rongwei Wang (1): elf: align the mapping address of LOAD segments with p_align elf/dl-load.c | 1 + elf/dl-map-segments.h | 60 ++++++++++++++++++++++++++++++++++++++++--- include/link.h | 3 +++ 3 files changed, 60 insertions(+), 4 deletions(-)