Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751633AbdLIRTz (ORCPT ); Sat, 9 Dec 2017 12:19:55 -0500 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:42157 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751149AbdLIRTx (ORCPT ); Sat, 9 Dec 2017 12:19:53 -0500 Date: Sat, 9 Dec 2017 18:19:58 +0100 From: Pavel Machek To: Michal Hocko Cc: Cyril Hrubis , John Hubbard , Michael Kerrisk , linux-man , linux-api@vger.kernel.org, Michael Ellerman , linux-mm@kvack.org, LKML , linux-arch@vger.kernel.org, Jann Horn , Matthew Wilcox Subject: Re: [PATCH v2] mmap.2: MAP_FIXED updated documentation Message-ID: <20171209171958.GB19862@localhost> References: <20171204021411.4786-1-jhubbard@nvidia.com> <20171204105549.GA31332@rei> <20171205070510.aojohhvixijk3i27@dhcp22.suse.cz> <2cff594a-b481-269d-dd91-ff2cc2f4100a@nvidia.com> <20171206100118.GA13979@rei> <20171207125805.GA1210@rei.lan> <20171207140221.GJ20234@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171207140221.GJ20234@dhcp22.suse.cz> 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: 1943 Lines: 40 On Thu 2017-12-07 15:02:21, Michal Hocko wrote: > On Thu 07-12-17 13:58:05, Cyril Hrubis wrote: > > Hi! > > > >> (It does seem unfortunate that the man page cannot help the programmer > > > >> actually write correct code here. He or she is forced to read the kernel > > > >> implementation, in order to figure out the true alignment rules. I was > > > >> hoping we could avoid that.) > > > > > > > > It would be nice if we had this information exported somehere so that we > > > > do not have to rely on per-architecture ifdefs. > > > > > > > > What about adding MapAligment or something similar to the /proc/meminfo? > > > > > > > > > > What's the use case you envision for that? I don't see how that would be > > > better than using SHMLBA, which is available at compiler time. Because > > > unless someone expects to be able to run an app that was compiled for > > > Arch X, on Arch Y (surely that's not requirement here?), I don't see how > > > the run-time check is any better. > > > > I guess that some kind of compile time constant in uapi headers will do > > as well, I'm really open to any solution that would expose this constant > > as some kind of official API. > > I am not sure this is really feasible. It is not only a simple alignment > thing. Look at ppc for example (slice_get_unmapped_area). Other > architectures might have even more complicated rules e.g. arm and its > cache_is_vipt_aliasing. Also this applies only on MAP_SHARED || file > backed mappings. > > I would really leave dogs sleeping... Trying to document all this in the > man page has chances to confuse more people than it has chances to help > those who already know all these nasty details. You don't have to provide all the details, but warning that there's arch- specific magic would be nice... Pavel (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html