Linux-Fsdevel Archive on lore.kernel.org
 help / color / Atom feed
From: Waiman Long <longman@redhat.com>
To: Qian Cai <cai@lca.pw>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>, Will Deacon <will.deacon@arm.com>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Mike Kravetz <mike.kravetz@oracle.com>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-mm@kvack.org, Davidlohr Bueso <dave@stgolabs.net>
Subject: Re: [PATCH 5/5] hugetlbfs: Limit wait time when trying to share huge PMD
Date: Wed, 11 Sep 2019 21:54:00 +0100
Message-ID: <211b144f-0e86-d891-e1ec-9879ceb53e36@redhat.com> (raw)
In-Reply-To: <70714929-2CE3-42F4-BD31-427077C9E24E@lca.pw>

On 9/11/19 8:42 PM, Qian Cai wrote:
>
>> On Sep 11, 2019, at 12:34 PM, Waiman Long <longman@redhat.com> wrote:
>>
>> On 9/11/19 5:01 PM, Qian Cai wrote:
>>>> On Sep 11, 2019, at 11:05 AM, Waiman Long <longman@redhat.com> wrote:
>>>>
>>>> When allocating a large amount of static hugepages (~500-1500GB) on a
>>>> system with large number of CPUs (4, 8 or even 16 sockets), performance
>>>> degradation (random multi-second delays) was observed when thousands
>>>> of processes are trying to fault in the data into the huge pages. The
>>>> likelihood of the delay increases with the number of sockets and hence
>>>> the CPUs a system has.  This only happens in the initial setup phase
>>>> and will be gone after all the necessary data are faulted in.
>>>>
>>>> These random delays, however, are deemed unacceptable. The cause of
>>>> that delay is the long wait time in acquiring the mmap_sem when trying
>>>> to share the huge PMDs.
>>>>
>>>> To remove the unacceptable delays, we have to limit the amount of wait
>>>> time on the mmap_sem. So the new down_write_timedlock() function is
>>>> used to acquire the write lock on the mmap_sem with a timeout value of
>>>> 10ms which should not cause a perceivable delay. If timeout happens,
>>>> the task will abandon its effort to share the PMD and allocate its own
>>>> copy instead.
>>>>
>>>> When too many timeouts happens (threshold currently set at 256), the
>>>> system may be too large for PMD sharing to be useful without undue delay.
>>>> So the sharing will be disabled in this case.
>>>>
>>>> Signed-off-by: Waiman Long <longman@redhat.com>
>>>> ---
>>>> include/linux/fs.h |  7 +++++++
>>>> mm/hugetlb.c       | 24 +++++++++++++++++++++---
>>>> 2 files changed, 28 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/include/linux/fs.h b/include/linux/fs.h
>>>> index 997a530ff4e9..e9d3ad465a6b 100644
>>>> --- a/include/linux/fs.h
>>>> +++ b/include/linux/fs.h
>>>> @@ -40,6 +40,7 @@
>>>> #include <linux/fs_types.h>
>>>> #include <linux/build_bug.h>
>>>> #include <linux/stddef.h>
>>>> +#include <linux/ktime.h>
>>>>
>>>> #include <asm/byteorder.h>
>>>> #include <uapi/linux/fs.h>
>>>> @@ -519,6 +520,12 @@ static inline void i_mmap_lock_write(struct address_space *mapping)
>>>> 	down_write(&mapping->i_mmap_rwsem);
>>>> }
>>>>
>>>> +static inline bool i_mmap_timedlock_write(struct address_space *mapping,
>>>> +					 ktime_t timeout)
>>>> +{
>>>> +	return down_write_timedlock(&mapping->i_mmap_rwsem, timeout);
>>>> +}
>>>> +
>>>> static inline void i_mmap_unlock_write(struct address_space *mapping)
>>>> {
>>>> 	up_write(&mapping->i_mmap_rwsem);
>>>> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
>>>> index 6d7296dd11b8..445af661ae29 100644
>>>> --- a/mm/hugetlb.c
>>>> +++ b/mm/hugetlb.c
>>>> @@ -4750,6 +4750,8 @@ void adjust_range_if_pmd_sharing_possible(struct vm_area_struct *vma,
>>>> 	}
>>>> }
>>>>
>>>> +#define PMD_SHARE_DISABLE_THRESHOLD	(1 << 8)
>>>> +
>>>> /*
>>>> * Search for a shareable pmd page for hugetlb. In any case calls pmd_alloc()
>>>> * and returns the corresponding pte. While this is not necessary for the
>>>> @@ -4770,11 +4772,24 @@ pte_t *huge_pmd_share(struct mm_struct *mm, unsigned long addr, pud_t *pud)
>>>> 	pte_t *spte = NULL;
>>>> 	pte_t *pte;
>>>> 	spinlock_t *ptl;
>>>> +	static atomic_t timeout_cnt;
>>>>
>>>> -	if (!vma_shareable(vma, addr))
>>>> -		return (pte_t *)pmd_alloc(mm, pud, addr);
>>>> +	/*
>>>> +	 * Don't share if it is not sharable or locking attempt timed out
>>>> +	 * after 10ms. After 256 timeouts, PMD sharing will be permanently
>>>> +	 * disabled as it is just too slow.
>>> It looks like this kind of policy interacts with kernel debug options like KASAN (which is going to slow the system down
>>> anyway) could introduce tricky issues due to different timings on a debug kernel.
>> With respect to lockdep, down_write_timedlock() works like a trylock. So
>> a lot of checking will be skipped. Also the lockdep code won't be run
>> until the lock is acquired. So its execution time has no effect on the
>> timeout.
> No only lockdep, but also things like KASAN, debug_pagealloc, page_poison, kmemleak, debug
> objects etc that  all going to slow down things in huge_pmd_share(), and make it tricky to get a
> right timeout value for those debug kernels without changing the previous behavior.

Right, I understand that. I will move to use a sysctl parameters for the
timeout and then set its default value to either 10ms or 20ms if some
debug options are detected. Usually the slower than should not be more
than 2X.

Cheers,
Longman


  reply index

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-11 15:05 [PATCH 0/5] hugetlbfs: Disable PMD sharing for large systems Waiman Long
2019-09-11 15:05 ` [PATCH 1/5] locking/rwsem: Add down_write_timedlock() Waiman Long
2019-09-11 15:05 ` [PATCH 2/5] locking/rwsem: Enable timeout check when spinning on owner Waiman Long
2019-09-11 15:05 ` [PATCH 3/5] locking/osq: Allow early break from OSQ Waiman Long
2019-09-11 15:05 ` [PATCH 4/5] locking/rwsem: Enable timeout check when staying in the OSQ Waiman Long
2019-09-11 15:05 ` [PATCH 5/5] hugetlbfs: Limit wait time when trying to share huge PMD Waiman Long
2019-09-11 15:14   ` Matthew Wilcox
2019-09-11 15:44     ` Waiman Long
2019-09-11 17:03       ` Mike Kravetz
2019-09-11 17:15         ` Waiman Long
2019-09-11 17:22           ` Qian Cai
2019-09-11 17:28           ` Waiman Long
2019-09-11 16:01   ` Qian Cai
2019-09-11 16:34     ` Waiman Long
2019-09-11 19:42       ` Qian Cai
2019-09-11 20:54         ` Waiman Long [this message]
2019-09-11 21:57           ` Qian Cai
2019-09-11 19:57   ` Matthew Wilcox
2019-09-11 20:51     ` Waiman Long
2019-09-12  3:26   ` Mike Kravetz
2019-09-12  3:41     ` Matthew Wilcox
2019-09-12  4:40       ` Davidlohr Bueso
2019-09-16 13:53         ` Waiman Long
2019-09-12  9:06     ` Waiman Long
2019-09-12 16:43       ` Mike Kravetz
2019-09-13 18:23         ` Waiman Long
2019-09-13  1:50 ` [PATCH 0/5] hugetlbfs: Disable PMD sharing for large systems Dave Chinner
2019-09-25  8:35   ` Peter Zijlstra

Reply instructions:

You may reply publically 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=211b144f-0e86-d891-e1ec-9879ceb53e36@redhat.com \
    --to=longman@redhat.com \
    --cc=cai@lca.pw \
    --cc=dave@stgolabs.net \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mike.kravetz@oracle.com \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=will.deacon@arm.com \
    /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

Linux-Fsdevel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-fsdevel/0 linux-fsdevel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-fsdevel linux-fsdevel/ https://lore.kernel.org/linux-fsdevel \
		linux-fsdevel@vger.kernel.org
	public-inbox-index linux-fsdevel

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-fsdevel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git