From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark H Weaver Subject: Re: heads-up: Haskell updates Date: Sat, 17 Feb 2018 14:54:58 -0500 Message-ID: <87bmgnjsrx.fsf@netris.org> References: <87r2ppjbst.fsf@elephly.net> <873723pfya.fsf@netris.org> <871shn8jm5.fsf@elephly.net> <87zi4b744f.fsf@elephly.net> <20180214234721.4e9fe198@scratchpost.org> <87a7waodaa.fsf@netris.org> <20180215120404.0a96b628@scratchpost.org> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:35739) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1en8a7-0006aS-4n for guix-devel@gnu.org; Sat, 17 Feb 2018 14:55:36 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1en8a4-0008GH-2z for guix-devel@gnu.org; Sat, 17 Feb 2018 14:55:35 -0500 Received: from world.peace.net ([50.252.239.5]:51246) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1en8a3-0008G3-UM for guix-devel@gnu.org; Sat, 17 Feb 2018 14:55:32 -0500 In-Reply-To: <20180215120404.0a96b628@scratchpost.org> (Danny Milosavljevic's message of "Thu, 15 Feb 2018 12:04:04 +0100") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Danny Milosavljevic Cc: guix-devel Hi Danny, Danny Milosavljevic writes: > On Thu, 15 Feb 2018 03:41:33 -0500 > Mark H Weaver wrote: > >> Given that it's using #ifdef to detect this, I'd expect the result to >> depend only on the _headers_ being used to compile, and not the actual >> kernel running the build. > > Yes, that's precisely the problem. > > * The [glibc or kernel] headers determine whether the ghc compilation detects it > * The Linux kernel determines whether the functionality is actually present at > runtime when any ghc program (like ghc-pkg) runs. > > Linus takes backward compatibility seriously - the constants > or functionality are not going to vanish from Linux later. > > So the only problematic case is that the build process finds MADV_FREE > but the running Linux doesn't yet have it and a ghc program runs on it. > > Reading MADV_DONTNEED docs again, MADV_DONTNEED pretty much does the same > as MADV_FREE - but MADV_DONTNEED promises to make later accesses to the > range succeed (by providing a new zero-filled page if necessary) while > MADV_FREE promises to make them fail. > > So one could fall back to MADV_DONTNEED - should be fine, though a little weird > for an allocator. > > If that's the case and the build still fails, let's just apply the Haskell patch > to ghc (or update ghc if there's a newer release). Unfortunately, the patch didn't fix the problem on Hydra, as I mentioned in another message: https://hydra.gnu.org/build/2501179 https://hydra.gnu.org/build/2501155 >> why it works for Ricardo but not for Andreas and Hydra. > > At runtime it depends on the Linux kernel version present whether > the deallocation will work or not. > > So I suspect that Ricardo has a Linux >= 4.5 but Andreas and Hydra > have a Linux < 4.5. Is that correct? This turned out to be incorrect. Andreas said he was running a Debian kernel, version 4.9.x. So, your analysis makes sense and is much appreciated, but the available evidence seems to suggest that something else might be going on. Any more ideas? Mark