Control: tag -1 moreinfo On Fri, 2014-09-12 at 09:37 +0200, Cyril Soldani wrote: > 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. [...] Please explain 'won't work'. I am able to create files on multiple hugetlbfs mounts. I suspect that some other application may be automatically using hugepages in /dev/hugepages, whereas previously there was no default location available for it to use. 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
Attachment:
signature.asc
Description: This is a digitally signed message part