From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pavel Machek Subject: Re: [Question] New mmap64 syscall? Date: Sat, 10 Dec 2016 10:10:01 +0100 Message-ID: <20161210091001.GA17896@xo-6d-61-c0.localdomain> References: <20161206185440.GA4654@yury-N73SV> <20161207163210.GB31779@e104818-lin.cambridge.arm.com> <12011325.PfzMMUCfyS@wuerfel> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Return-path: Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:57763 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752183AbcLJPSK (ORCPT ); Sat, 10 Dec 2016 10:18:10 -0500 Content-Disposition: inline In-Reply-To: <12011325.PfzMMUCfyS@wuerfel> Sender: linux-arch-owner@vger.kernel.org List-ID: To: Arnd Bergmann Cc: "Dr. Philipp Tomsich" , Catalin Marinas , Yury Norov , libc-alpha@sourceware.org, linux-arch@vger.kernel.org, LKML , szabolcs.nagy@arm.com, heiko.carstens@de.ibm.com, cmetcalf@ezchip.com, "Joseph S. Myers" , zhouchengming1@huawei.com, "Kapoor, Prasun" , Alexander Graf , geert@linux-m68k.org, kilobyte@angband.pl, manuel.montezelo@gmail.com, Andrew Pinski , linyongting@huawei.com, Alexey Klimov , broonie@kernel.org, "Zhangjian (Bamvor)" , linux-arm-kernel , Maxim Hi! > > Most of these advantages should eventually go away, when struct-reorg makes > > it way into the compiler. That said, it’s a marginal (but real) improvement for a > > subset of SPEC. > > > > In the real world, the importance of ILP32 as an aid to transition legacy code > > that is not 64bit clean… and this should drive the ILP32 discussion. That we > > get a boost in our SPEC scores is just a nice extra that we get from it > > To bring this back from the philosophical questions of ABI design > to the specific point of what file offset width you want for mmap() > on 32-bit architectures. > > For all I can tell, using mmap() to access a file that is many thousand > times larger than your virtual address space is completely crazy. Dunno. Wanting to mmap part of a partition does not seem too crazy... I'm pretty sure there's some tool out there that uses mmap(), just because mmap() was nicer to use then read(). And when the partition is big, the offset may be big. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:57763 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752183AbcLJPSK (ORCPT ); Sat, 10 Dec 2016 10:18:10 -0500 Date: Sat, 10 Dec 2016 10:10:01 +0100 From: Pavel Machek Subject: Re: [Question] New mmap64 syscall? Message-ID: <20161210091001.GA17896@xo-6d-61-c0.localdomain> References: <20161206185440.GA4654@yury-N73SV> <20161207163210.GB31779@e104818-lin.cambridge.arm.com> <12011325.PfzMMUCfyS@wuerfel> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8BIT In-Reply-To: <12011325.PfzMMUCfyS@wuerfel> Sender: linux-arch-owner@vger.kernel.org List-ID: To: Arnd Bergmann Cc: "Dr. Philipp Tomsich" , Catalin Marinas , Yury Norov , libc-alpha@sourceware.org, linux-arch@vger.kernel.org, LKML , szabolcs.nagy@arm.com, heiko.carstens@de.ibm.com, cmetcalf@ezchip.com, "Joseph S. Myers" , zhouchengming1@huawei.com, "Kapoor, Prasun" , Alexander Graf , geert@linux-m68k.org, kilobyte@angband.pl, manuel.montezelo@gmail.com, Andrew Pinski , linyongting@huawei.com, Alexey Klimov , broonie@kernel.org, "Zhangjian (Bamvor)" , linux-arm-kernel , Maxim Kuvyrkov , Nathan Lynch , Martin Schwidefsky , davem@davemloft.net, christoph.muellner@theobroma-systems.com Message-ID: <20161210091001.9kgN2NA8KJadUjxap5_GAcru_CXkVlPgPr0U6ehkK0k@z> Hi! > > Most of these advantages should eventually go away, when struct-reorg makes > > it way into the compiler. That said, it’s a marginal (but real) improvement for a > > subset of SPEC. > > > > In the real world, the importance of ILP32 as an aid to transition legacy code > > that is not 64bit clean… and this should drive the ILP32 discussion. That we > > get a boost in our SPEC scores is just a nice extra that we get from it > > To bring this back from the philosophical questions of ABI design > to the specific point of what file offset width you want for mmap() > on 32-bit architectures. > > For all I can tell, using mmap() to access a file that is many thousand > times larger than your virtual address space is completely crazy. Dunno. Wanting to mmap part of a partition does not seem too crazy... I'm pretty sure there's some tool out there that uses mmap(), just because mmap() was nicer to use then read(). And when the partition is big, the offset may be big. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html