Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753230AbcLJP3k convert rfc822-to-8bit (ORCPT ); Sat, 10 Dec 2016 10:29:40 -0500 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:58043 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752419AbcLJP3j (ORCPT ); Sat, 10 Dec 2016 10:29:39 -0500 Date: Sat, 10 Dec 2016 10:21:30 +0100 From: Pavel Machek 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 Subject: Re: [Question] New mmap64 syscall? Message-ID: <20161210092130.GA19309@xo-6d-61-c0.localdomain> References: <20161206185440.GA4654@yury-N73SV> <20161207163210.GB31779@e104818-lin.cambridge.arm.com> <12011325.PfzMMUCfyS@wuerfel> <20161210091001.GA17896@xo-6d-61-c0.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8BIT In-Reply-To: <20161210091001.GA17896@xo-6d-61-c0.localdomain> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1455 Lines: 31 On Sat 2016-12-10 10:10:01, Pavel Machek wrote: > 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. Actually, if I wrote something like jpegrecover, I'd use mmap() for that (because otherwise I'd be keeping copy of disk in anonymous memory, increasing memory pressure). jpegrecover definitely makes sense on partitions... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html