From: Yang Shi <email@example.com> To: Hugh Dickins <firstname.lastname@example.org> Cc: Andrew Morton <email@example.com>, Shakeel Butt <firstname.lastname@example.org>, "Kirill A. Shutemov" <email@example.com>, Miaohe Lin <firstname.lastname@example.org>, Mike Kravetz <email@example.com>, Michal Hocko <firstname.lastname@example.org>, Rik van Riel <email@example.com>, Christoph Hellwig <firstname.lastname@example.org>, Matthew Wilcox <email@example.com>, "Eric W. Biederman" <firstname.lastname@example.org>, Alexey Gladkov <email@example.com>, Chris Wilson <firstname.lastname@example.org>, Matthew Auld <email@example.com>, Linux FS-devel Mailing List <firstname.lastname@example.org>, Linux Kernel Mailing List <email@example.com>, firstname.lastname@example.org, Linux MM <email@example.com> Subject: Re: [PATCH 06/16] huge tmpfs: shmem_is_huge(vma, inode, index) Date: Fri, 6 Aug 2021 10:57:32 -0700 [thread overview] Message-ID: <CAHbLzkou+6m+htMNzSQrHfd6U0yURWiewK=Pvg30XSdiWfirstname.lastname@example.org> (raw) In-Reply-To: <email@example.com> On Thu, Aug 5, 2021 at 10:43 PM Hugh Dickins <firstname.lastname@example.org> wrote: > > On Thu, 5 Aug 2021, Yang Shi wrote: > > > > By rereading the code, I think you are correct. Both cases do work > > correctly without leaking. And the !CONFIG_NUMA case may carry the > > huge page indefinitely. > > > > I think it is because khugepaged may collapse memory for another NUMA > > node in the next loop, so it doesn't make too much sense to carry the > > huge page, but it may be an optimization for !CONFIG_NUMA case. > > Yes, that is its intention. > > > > > However, as I mentioned in earlier email the new pcp implementation > > could cache THP now, so we might not need keep this convoluted logic > > anymore. Just free the page if collapse is failed then re-allocate > > THP. The carried THP might improve the success rate a little bit but I > > doubt how noticeable it would be, may be not worth for the extra > > complexity at all. > > It would be great if the new pcp implementation is good enough to > get rid of khugepaged's confusing NUMA=y/NUMA=n differences; and all > the *hpage stuff too, I hope. That would be a welcome cleanup. The other question is if that optimization is worth it nowadays or not. I bet not too many users build NUMA=n kernel nowadays even though the kernel is actually running on a non-NUMA machine. Some small devices may run NUMA=n kernel, but I don't think they actually use THP. So such code complexity could be removed from this point of view too. > > > > > Collapse failure is not uncommon and leaking huge pages gets noticed. > > After writing that, I realized how I'm almost always testing a NUMA=y > kernel (though on non-NUMA machines), and seldom try the NUMA=n build. > So did so to check no leak, indeed; but was surprised, when comparing > vmstats, that the NUMA=n run had done 5 times as much thp_collapse_alloc > as the NUMA=y run. I've merely made a note to look into that one day: > maybe it was just a one-off oddity, or maybe the incrementing of stats > is wrong down one path or the other. Yeah, probably. > > Hugh
next prev parent reply other threads:[~2021-08-06 17:57 UTC|newest] Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-07-30 7:22 [PATCH 00/16] tmpfs: HUGEPAGE and MEM_LOCK fcntls and memfds Hugh Dickins 2021-07-30 7:25 ` [PATCH 01/16] huge tmpfs: fix fallocate(vanilla) advance over huge pages Hugh Dickins 2021-07-30 21:36 ` Yang Shi 2021-08-01 3:38 ` Hugh Dickins 2021-08-02 20:36 ` Yang Shi 2021-07-30 7:28 ` [PATCH 02/16] huge tmpfs: fix split_huge_page() after FALLOC_FL_KEEP_SIZE Hugh Dickins 2021-07-30 23:48 ` Yang Shi 2021-07-30 7:30 ` [PATCH 03/16] huge tmpfs: remove shrinklist addition from shmem_setattr() Hugh Dickins 2021-07-30 21:50 ` Yang Shi 2021-07-30 7:36 ` [PATCH 04/16] huge tmpfs: revert shmem's use of transhuge_vma_enabled() Hugh Dickins 2021-07-30 21:56 ` Yang Shi 2021-08-01 4:01 ` Hugh Dickins 2021-08-02 20:39 ` Yang Shi 2021-07-30 7:39 ` [PATCH 05/16] huge tmpfs: move shmem_huge_enabled() upwards Hugh Dickins 2021-07-30 21:57 ` Yang Shi 2021-07-30 7:42 ` [PATCH 06/16] huge tmpfs: shmem_is_huge(vma, inode, index) Hugh Dickins 2021-07-30 23:34 ` Yang Shi 2021-08-01 5:22 ` Hugh Dickins 2021-08-01 5:37 ` Hugh Dickins 2021-08-02 21:14 ` Yang Shi 2021-08-04 8:28 ` Hugh Dickins 2021-08-04 19:01 ` Yang Shi 2021-08-06 5:21 ` Hugh Dickins 2021-08-06 17:41 ` Yang Shi 2021-08-05 23:04 ` Yang Shi 2021-08-06 5:43 ` Hugh Dickins 2021-08-06 17:57 ` Yang Shi [this message] 2021-08-12 18:19 ` Yang Shi 2021-07-30 7:45 ` [PATCH 07/16] memfd: memfd_create(name, MFD_HUGEPAGE) for shmem huge pages Hugh Dickins 2021-08-04 14:03 ` Kirill A. Shutemov 2021-08-06 3:33 ` Hugh Dickins 2021-07-30 7:48 ` [PATCH 08/16] huge tmpfs: fcntl(fd, F_HUGEPAGE) and fcntl(fd, F_NOHUGEPAGE) Hugh Dickins 2021-08-04 14:08 ` Kirill A. Shutemov 2021-08-06 4:34 ` Hugh Dickins 2021-07-30 7:51 ` [PATCH 09/16] huge tmpfs: decide stat.st_blksize by shmem_is_huge() Hugh Dickins 2021-07-30 23:40 ` Yang Shi 2021-07-30 7:55 ` [PATCH 10/16] tmpfs: fcntl(fd, F_MEM_LOCK) to memlock a tmpfs file Hugh Dickins 2021-08-03 1:38 ` Matthew Wilcox 2021-08-04 9:15 ` Hugh Dickins 2021-07-30 7:57 ` [PATCH 11/16] tmpfs: fcntl(fd, F_MEM_LOCKED) to test if memlocked Hugh Dickins 2021-07-30 8:00 ` [PATCH 12/16] tmpfs: refuse memlock when fallocated beyond i_size Hugh Dickins 2021-07-30 8:03 ` [PATCH 13/16] mm: bool user_shm_lock(loff_t size, struct ucounts *) Hugh Dickins 2021-07-30 8:06 ` [PATCH 14/16] mm: user_shm_lock(,,getuc) and user_shm_unlock(,,putuc) Hugh Dickins 2021-07-30 8:09 ` [PATCH 15/16] tmpfs: permit changing size of memlocked file Hugh Dickins 2021-07-30 8:13 ` [PATCH 16/16] memfd: memfd_create(name, MFD_MEM_LOCK) for memlocked shmem Hugh Dickins
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAHbLzkou+6m+htMNzSQrHfd6U0yURWiewK=Pvg30XSdiWemail@example.com' \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH 06/16] huge tmpfs: shmem_is_huge(vma, inode, index)' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).