Thread (1 message) 1 message, 1 author, 2016-04-20

[PATCHv7 00/29] THP-enabled tmpfs/shmem using compound pages

From: hughd@google.com (Hugh Dickins)
Date: 2016-04-20 08:31:42
Also in: linux-fsdevel, linux-mm, lkml

On Mon, 18 Apr 2016, Shi, Yang wrote:
Hi Kirill,

Finally, I got some time to look into and try yours and Hugh's patches, got
Thank you.
two problems.

1. A quick boot up test on my ARM64 machine with your v7 tree shows some
unexpected error:

systemd-journald[285]: Failed to save stream data
/run/systemd/journal/streams/8:16863: No space left on device
systemd-journald[285]: Failed to save stream data
/run/systemd/journal/streams/8:16865: No space left on device
         Starting DNS forwarder and DHCP server.systemd-journald[285]: Failed
to save stream data /run/systemd/journal/streams/8:16867: No space left on
device
..
systemd-journald[285]: Failed to save stream data
/run/systemd/journal/streams/8:16869: No space left on device
         Starting Postfix Mail Transport Agent...
systemd-journald[285]: Failed to save stream data
/run/systemd/journal/streams/8:16871: No space left on device
         Starting Berkeley Internet Name Domain (DNS)...
         Starting Wait for Network to be Configured...
systemd-journald[285]: Failed to save stream data
/run/systemd/journal/streams/8:2422: No space left on device
[  OK  ] Started /etc/rc.local Compatibility.
[FAILED] Failed to start DNS forwarder and DHCP server.
See 'systemctl status dnsmasq.service' for details.
systemd-journald[285]: Failed to save stream data
/run/systemd/journal/streams/8:2425: No space left on device
[  OK  ] Started Serial Getty on ttyS1.
[  OK  ] Started Serial Getty on ttyS0.
[  OK  ] Started Getty on tty1.
systemd-journald[285]: Failed to save stream data
/run/systemd/journal/streams/8:2433: No space left on device
[FAILED] Failed to start Berkeley Internet Name Domain (DNS).
See 'systemctl status named.service' for details.
Expected behaviour: that is a significant limitation of Kirill's current
implementation.  We have agreed at LSF/MM that he will fix that before
his patchset goes further.  (And different changes needed in my patchset.)

The /run dir is mounted as tmpfs.

x86 boot doesn't get such error. And, Hugh's patches don't have such problem.

2. I ran my THP test (generated a program with 4MB text section) on both
x86-64 and ARM64 with yours and Hugh's patches (linux-next tree), I got the
program execution time reduced by ~12% on x86-64, it looks very impressive.
12% sounds about right for x86.  Some loads have been seen to benefit 17%.
But, on ARM64, there is just ~3% change, and sometimes huge tmpfs may show
even worse data than non-hugepage.

Both yours and Hugh's patches has the same behavior.

Any idea?
... and in a later posting..,
It would be better if Kirill and Hugh could share what benchmark they ran and
how much they got improved since my test case is very simple and may just
cover a small part of it.
Sorry, I've not run any benchmark myself (prefer to let others get more
objective results), nor run on arm64.  I have no idea what to expect on
arm64 - you need to ask the arm64 guys what hugepage advantage they see
with anon THP or hugetlbfs (and probably need to tell them what machine
you're running on): then expect a similar advantage from either Kirill's
or my huge tmpfs patchset.

Hugh
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help