Bug#761257: systemd: disrupts hugepages support

[Cyril Soldani]

On Fri, 12 Sep 2014 19:25:21 +0200
m...@linux.it (Marco d'Itri) wrote:
> > 1) systemd *not* messing with the existing hugepages setup;
>
> This will not happen: it would be too much complex and anyway the new 
> "standard" location is /dev/hugepages/ .

It looks questionable to me, but you certainly know better (as I
don't know anything about it) and I won't argue any further.

> > 2) being warned when installing systemd-sysv that systemd handles
> >hugepages differently (especially when I have hugepages entries
> >in my fstab).
>
> But I think that we can add a preinst check, can you provide a simple 
> shell test case that checks for this condition?

I must first mention that the problem is less severe than initially
thought. As Ben Hutchings helped me discover (see #761299), you can
still use hugepages even when mounted several times. Our problem was
that the two mount points had different permissions, and our
applications were using the wrong one. It thus likely to affect less
users than initially thought.

If you are still willing to add a warning (which could still be nice,
IMO), a test like this might be sufficient:

if 2>&1 grep -E '^[^#]*hugetlbfs' /etc/fstab >/dev/null; then
echo "Hugepages entries found"
fi

Regards,
-- 
"The nationalist not only does not disapprove of atrocities committed
 by his own side, he has a remarkable capacity for not even hearing
 about them."George Orwell

Cyril Soldani 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#761257: systemd: disrupts hugepages support

[Ben Hutchings]

On Fri, 2014-09-12 at 19:25 +0200, Marco d'Itri wrote:
> On Sep 12, Cyril Soldani  wrote:
> 
> > 1) systemd *not* messing with the existing hugepages setup;
> This will not happen: it would be too much complex and anyway the new 
> "standard" location is /dev/hugepages/ .
> 
> > 2) being warned when installing systemd-sysv that systemd handles
> >hugepages differently (especially when I have hugepages entries in my
> >fstab).
> But I think that we can add a preinst check, can you provide a simple 
> shell test case that checks for this condition?

First we should establish whether there is an actual bug in the kernel.

Ben.

-- 
Ben Hutchings
I'm always amazed by the number of people who take up solipsism because
they heard someone else explain it. - E*Borg on alt.fan.pratchett


signature.asc
Description: This is a digitally signed message part

Bug#761257: systemd: disrupts hugepages support

[Marco d'Itri]

On Sep 12, Cyril Soldani  wrote:

> 1) systemd *not* messing with the existing hugepages setup;
This will not happen: it would be too much complex and anyway the new 
"standard" location is /dev/hugepages/ .

> 2) being warned when installing systemd-sysv that systemd handles
>hugepages differently (especially when I have hugepages entries in my
>fstab).
But I think that we can add a preinst check, can you provide a simple 
shell test case that checks for this condition?

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Bug#761257: systemd: disrupts hugepages support

[Cyril Soldani]

Package: systemd
Version: 208-8
Severity: normal

Dear Maintainer,

We are developing Intel DPDK applications on several Debian-powered
servers. Those applications make use of 1GB huge pages, allocated
through kernel parameters in /etc/defaults/grub, and an entry in
/etc/fstab to mount them in /mnt/huge_1GB.

After some upgrades, our applications stopped working on most servers
due to hugepages being unavailable. They were still appearing in
/proc/meminfo but were neither free, nor reserved.

After hours of debugging (we had also updated Intel DPDK so we thought
that was the culprit), we noticed a difference between the failing
servers and the ones still working was that systemd was running as init
on the failing ones and not on the working ones.

We tried uninstalling systemd-sysv (installing sysvinit-core and
systemd-shim), rebooting, and then it worked as before.

After investigations, it looks like systemd, when run as init, mounts
the hugepages in /dev/hugepages (IMHO, an unexpected place for a mount
point), before them being remounted on /mnt/huge_1GB as per fstab. It
looks like hugepages won't work when mounted twice.

A likely culprit is /lib/systemd/system/dev-hugepages.mount.

The workaround looks trivial (remove fstab entry and link /dev/hugepages
to /mnt/huge_1GB), but I still have the feeling this should not have
happened in the first place, hence this bug report.

I would expect either (by order of preference):
1) systemd *not* messing with the existing hugepages setup;
2) being warned when installing systemd-sysv that systemd handles
   hugepages differently (especially when I have hugepages entries in my
   fstab).

-- Package-specific info:

-- System Information:
Debian Release: jessie/sid
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.14-2-amd64 (SMP w/12 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages systemd depends on:
ii  acl  2.2.52-1.1
ii  adduser  3.113+nmu3
ii  initscripts  2.88dsf-53.4
ii  libacl1  2.2.52-1.1
ii  libaudit11:2.3.7-1
ii  libblkid12.20.1-5.8
ii  libc62.19-10
ii  libcap2  1:2.24-4
ii  libcap2-bin  1:2.24-4
ii  libcryptsetup4   2:1.6.6-1
ii  libdbus-1-3  1.8.6-2
ii  libgcrypt11  1.5.4-3
ii  libkmod2 18-1
ii  liblzma5 5.1.1alpha+20120614-2
ii  libpam0g 1.1.8-3.1
ii  libselinux1  2.3-2
ii  libsystemd-daemon0   208-8
ii  libsystemd-journal0  208-8
ii  libsystemd-login0208-8
ii  libudev1 208-8
ii  libwrap0 7.6.q-25
ii  sysv-rc  2.88dsf-53.4
ii  udev 208-8
ii  util-linux   2.20.1-5.8

Versions of packages systemd recommends:
ii  libpam-systemd  208-8

Versions of packages systemd suggests:
pn  systemd-ui  

-- no debconf information
0 overridden configuration files found.
==> 
/var/lib/systemd/deb-systemd-helper-enabled/dbus-org.freedesktop.nm-dispatcher.service
 <==

==> 
/var/lib/systemd/deb-systemd-helper-enabled/bluetooth.target.wants/bluetooth.service
 <==

==> /var/lib/systemd/deb-systemd-helper-enabled/dbus-org.bluez.service <==

==> /var/lib/systemd/deb-systemd-helper-enabled/acpid.service.dsh-also <==
/etc/systemd/system/multi-user.target.wants/acpid.service

==> /var/lib/systemd/deb-systemd-helper-enabled/avahi-daemon.socket.dsh-also <==
/etc/systemd/system/sockets.target.wants/avahi-daemon.socket

==> 
/var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/atd.service 
<==

==> 
/var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/anacron.service
 <==

==> 
/var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/cron.service
 <==

==> 
/var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/avahi-daemon.service
 <==

==> 
/var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/rsyslog.service
 <==

==> 
/var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/ssh.service 
<==

==> 
/var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/binfmt-support.service
 <==

==> 
/var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/lm-sensors.service
 <==

==> 
/var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/pppd-dns.service
 <==

==> 
/var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/NetworkManager.service
 <==

==> 
/var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/ModemManager.service
 <==

==> /var/lib/systemd/deb-systemd-helper-enabled/lvm2-lvmetad.socket.dsh-also <==
/etc/systemd/system/sockets.target.wants/lvm2-lvmetad.socket
/etc/systemd/system/sysinit.target.wants/lvm2-lvmetad.socket

==> /var/lib/systemd/deb-systemd-helper-enabled/lm-sensors.service.dsh-also <==
/etc/systemd/system/multi-user