Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1451293

Re: [PATCHv1, RFC 00/33] ext4: support of huge pages

From Andrea Arcangeli <aarcange@redhat.com>
Newsgroups linux.kernel
Subject Re: [PATCHv1, RFC 00/33] ext4: support of huge pages
Date 2016-07-27 16:10 +0200
Message-ID <rZxH3-pG-5@gated-at.bofh.it> (permalink)
References <rYYzD-3py-7@gated-at.bofh.it> <rZeuK-4Z7-13@gated-at.bofh.it> <rZg3v-616-23@gated-at.bofh.it> <rZtap-5SB-5@gated-at.bofh.it> <rZupP-6Bc-5@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


Hello,

On Wed, Jul 27, 2016 at 01:33:35PM +0300, Kirill A. Shutemov wrote:
> I guess you can get work 64k blocks with 4k pages if you *always* allocate
> order-4 pages for page cache of the filesystem. But I don't think it's
> sustainable. It's significant pressure on buddy allocator and compaction.

Agreed.

To guarantee compaction to succeed for a certain percentage of the RAM
kernelcore= would need to be used, but the bigger the movable zone is,
the bigger the imbalance will be, because the memory used by the
kernel cannot use the RAM that is in the movable zone. If the movable
zone is too big, early OOM failures may materialize where the kernel
hits OOM despite there's plenty of free memory in the movable zone.
So it's not ideal.

> I guess the right approach would a mechanism to scatter one block to
> multiple order-0 pages. At least for fallback.

That would be ideal to avoid having to mess with kernelcore=, because
no matter what direct compaction does (and current direction
compaction defaults wouldn't be aggressive enough anyway), without
kernelcore= the THP (or order4) allocation can fail at times.

THP always requires a fallback so that a compaction failure isn't
fatal and it can actually be fixed up later by khugepaged as more free
memory becomes available at runtime.

Thanks,
Andrea

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCHv1, RFC 00/33] ext4: support of huge pages "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> - 2016-07-26 02:50 +0200
  [PATCHv1, RFC 30/33] ext4: relax assert in ext4_da_page_release_reservation() "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> - 2016-07-26 02:50 +0200
  [PATCHv1, RFC 32/33] mm, fs, ext4: expand use of page_mapping() and page_to_pgoff() "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> - 2016-07-26 02:50 +0200
  [PATCHv1, RFC 28/33] ext4: handle huge pages in __ext4_block_zero_page_range() "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> - 2016-07-26 02:50 +0200
  [PATCHv1, RFC 06/33] radix-tree: Handle multiorder entries being deleted by replace_clear_tags "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> - 2016-07-26 02:50 +0200
  [PATCHv1, RFC 07/33] mm, shmem: swich huge tmpfs to multi-order radix-tree entries "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> - 2016-07-26 02:50 +0200
  [PATCHv1, RFC 18/33] HACK: block: bump BIO_MAX_PAGES "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> - 2016-07-26 02:50 +0200
  [PATCHv1, RFC 20/33] thp: introduce hpage_size() and hpage_mask() "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> - 2016-07-26 02:50 +0200
  Re: [PATCHv1, RFC 00/33] ext4: support of huge pages Theodore Ts'o <tytso@mit.edu> - 2016-07-26 19:40 +0200
    Re: [PATCHv1, RFC 00/33] ext4: support of huge pages "Kirill A. Shutemov" <kirill@shutemov.name> - 2016-07-26 21:20 +0200
      Re: [PATCHv1, RFC 00/33] ext4: support of huge pages Jan Kara <jack@suse.cz> - 2016-07-27 11:20 +0200
        Re: [PATCHv1, RFC 00/33] ext4: support of huge pages "Kirill A. Shutemov" <kirill@shutemov.name> - 2016-07-27 12:40 +0200
          Re: [PATCHv1, RFC 00/33] ext4: support of huge pages Andrea Arcangeli <aarcange@redhat.com> - 2016-07-27 16:10 +0200
  [PATCH] mm, hugetlb: switch hugetlbfs to multi-order radix-tree  entries Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> - 2016-08-10 03:00 +0200

csiph-web