From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out30-43.freemail.mail.aliyun.com (out30-43.freemail.mail.aliyun.com [115.124.30.43]) by sourceware.org (Postfix) with ESMTPS id 2CDF83858C60 for ; Mon, 6 Dec 2021 02:48:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2CDF83858C60 X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R181e4; CH=green; DM=||false|; DS=||; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e01e04426; MF=rongwei.wang@linux.alibaba.com; NM=1; PH=DS; RN=4; SR=0; TI=SMTPD_---0UzU3D3u_1638758877; Received: from 30.240.97.92(mailfrom:rongwei.wang@linux.alibaba.com fp:SMTPD_---0UzU3D3u_1638758877) by smtp.aliyun-inc.com(127.0.0.1); Mon, 06 Dec 2021 10:47:58 +0800 Message-ID: <35a5148c-8a31-bdbd-d034-4de865090070@linux.alibaba.com> Date: Mon, 6 Dec 2021 10:47:56 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:95.0) Gecko/20100101 Thunderbird/95.0 Subject: Re: [PATCH RFC 1/1] elf: align the mapping address of LOAD segments with p_align Content-Language: en-US To: Florian Weimer , Rongwei Wang via Libc-alpha Cc: xuyu@linux.alibaba.com, gavin.dg@linux.alibaba.com References: <20211204045848.71105-1-rongwei.wang@linux.alibaba.com> <20211204045848.71105-2-rongwei.wang@linux.alibaba.com> <87wnkktf53.fsf@oldenburg.str.redhat.com> From: Rongwei Wang In-Reply-To: <87wnkktf53.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-13.7 required=5.0 tests=BAYES_00, ENV_AND_HDR_SPF_MATCH, KAM_DMARC_STATUS, NICE_REPLY_A, 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-List-Received-Date: Mon, 06 Dec 2021 02:48:02 -0000 Hi, Florian On 12/5/21 2:10 AM, Florian Weimer wrote: > * Rongwei Wang via Libc-alpha: > >> Now, ld.so always map the LOAD segments and aligned by base >> page size (e.g. 4k in x86 or 4k, 16k and 64k in arm64). And >> this patch improve the scheme here. In this patch, ld.so >> can align the mapping address of the first LOAD segment with >> p_align when p_align is greater than the current base page >> size. >> >> And this change makes code segments using huge pages become >> simple and available. > > I feel like we should be able to tell the kernel that we want an aligned > mapping. munmap is not actually cheap. I see munmap here will slow down applications linking to DSO. And the effect seems small? Sorry, I don't know much about this impact. Of course, I know that this effect should be magnified if the applications has too many DSOs. > > Do you know if there are some ideas in this area? Perhaps with another As far as I can tell, there are two methods to make .text use huge pages: 1. The way above mentioned: madvise + khugepaged; 2. use libhugetlbfs[1]: this way need to recompile the source code of application, and linking libhugetlbfs.so. The abvious difference is this way uses hugetlb. For application, the two methods mentioned above which seems not friendly to applications. > MAP_ flag and encoding the requested alignment in the lower bits of the Actually, It seems the kernel developers don't want to introduce new MAP_ flags to support this. Maybe they think mmap and munmap is enough for applications to get an aligned mapping address. And of course, it is just my guess and self point. In additions, back to the patch, what do you think of the alignment method used in our patch? There would be 4k, 64k and 2M to align the mapping in our patch, according to p_align value. If we try to introduce new MAP_ flags in kernel, I am not sure whether we need to add multiple flags, for example MAP_64K, MAP_2M, etc. LINK[1]: https://github.com/libhugetlbfs/libhugetlbfs Thanks! > hints address? > > Thanks, > Florian >