From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40721) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eRpS2-0001z0-5E for guix-patches@gnu.org; Wed, 20 Dec 2017 20:15:15 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eRpRv-0008Ac-9n for guix-patches@gnu.org; Wed, 20 Dec 2017 20:15:10 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:36314) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eRpRu-00089f-Tv for guix-patches@gnu.org; Wed, 20 Dec 2017 20:15:03 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eRpRt-0000Dd-M0 for guix-patches@gnu.org; Wed, 20 Dec 2017 20:15:02 -0500 Subject: [bug#29409] Remove hugetlb control group on ARM32. Resent-Message-ID: References: <877euhtjkj.fsf@gmail.com> <87ind19pok.fsf@gmail.com> From: Tobias Geerinckx-Rice Message-ID: Date: Thu, 21 Dec 2017 02:16:52 +0100 MIME-Version: 1.0 In-Reply-To: <87ind19pok.fsf@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: m.othacehe@gmail.com, 29409@debbugs.gnu.org Mathieu! (and others), Mathieu Othacehe wrote on 20/12/17 at 20:15: > Mounting %control-groups fails on ARM32 platform because we build a > kernel without LPAE support which implies hugetlb control group cannot > be supported. What happens when the mount fails? At first glance, %control-groups aren't needed-for-boot. Unfortunately, I'm not able to test it now: it's all disgustingly hypothetical from here on. > Like Debian we could have an ARMMP and ARMMP-LPAE kernel but the problem > would still exists for ARMMP. > > I'm not sure what do about, a workaround could be the ugly hack > attached, WDYT ? So to me your patch implies that mounting the hugetlb cgroup is entirely optional, and that no other (known) services will actually break if it's not mounted. %control-groups are mounted as part of %base-file-systems, about which the manual: -- Scheme Variable: %base-file-systems These are essential file systems that are required on normal systems, such as %PSEUDO-TERMINAL-FILE-SYSTEM and %IMMUTABLE-STORE (see below.) Operating system declarations should always contain at least these. In practice, %base-file-systems depends on more mounts than it probably should, since some of them aren't essential and some can't even exist on some platforms. That keeps things simple, and isn't a problem *if* mounting optional file systems like %control-groups simply logs the error and continues normally with the next mount. A bit dirty, perhaps, but there are more places in file-systems.scm that feel that way to me. If the patch only serves to suppress such an error, I don't think it's worth copying details of our kernel configurations around. If it fixes a broken boot, there's something... off about the way we handle mounts. ...or maybe I am. Thoughts? > From 2172a1897a9729b65767bb58883247a3c604109f Mon Sep 17 00:00:00 2001 > From: Mathieu Othacehe > Date: Wed, 20 Dec 2017 20:02:33 +0100 > Subject: [PATCH] file-systems: Do not mount hugetlb cgroup filesystem on > arm32. > > On ARM32 without LPAE support, hugetlb control group is not supported. Whenever I write an ‘extra’ line like this one, I usually realise it's really a comment in disguise, more at home in the code than forgotten in the commit log. I think that's the case here. Kind regards, T G-R