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 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
