On 6/29/18 4:39 AM, Michal Hocko wrote:
On Thu 28-06-18 17:59:25, Yang Shi wrote:
On 6/28/18 12:10 PM, Yang Shi wrote:
On 6/28/18 4:51 AM, Michal Hocko wrote:
On Wed 27-06-18 10:23:39, Yang Shi wrote:
On 6/27/18 12:24 AM, Michal Hocko wrote:
On Tue 26-06-18 18:03:34, Yang Shi wrote:
On
On 6/29/18 4:34 AM, Michal Hocko wrote:
On Thu 28-06-18 12:10:10, Yang Shi wrote:
On 6/28/18 4:51 AM, Michal Hocko wrote:
On Wed 27-06-18 10:23:39, Yang Shi wrote:
On 6/27/18 12:24 AM, Michal Hocko wrote:
On Tue 26-06-18 18:03:34, Yang Shi wrote:
On 6/26/18 12:43 AM, Peter Zijlstra wrote
On Thu 28-06-18 17:59:25, Yang Shi wrote:
>
>
> On 6/28/18 12:10 PM, Yang Shi wrote:
> >
> >
> > On 6/28/18 4:51 AM, Michal Hocko wrote:
> > > On Wed 27-06-18 10:23:39, Yang Shi wrote:
> > > >
> > > > On 6/27/18 12:24 AM, Michal Hocko wrote:
> > > > > On Tue 26-06-18 18:03:34, Yang Shi wrote:
On Thu 28-06-18 12:10:10, Yang Shi wrote:
>
>
> On 6/28/18 4:51 AM, Michal Hocko wrote:
> > On Wed 27-06-18 10:23:39, Yang Shi wrote:
> > >
> > > On 6/27/18 12:24 AM, Michal Hocko wrote:
> > > > On Tue 26-06-18 18:03:34, Yang Shi wrote:
> > > > > On 6/26/18 12:43 AM, Peter Zijlstra wrote:
> > >
On 6/28/18 12:10 PM, Yang Shi wrote:
On 6/28/18 4:51 AM, Michal Hocko wrote:
On Wed 27-06-18 10:23:39, Yang Shi wrote:
On 6/27/18 12:24 AM, Michal Hocko wrote:
On Tue 26-06-18 18:03:34, Yang Shi wrote:
On 6/26/18 12:43 AM, Peter Zijlstra wrote:
On Mon, Jun 25, 2018 at 05:06:23PM -0700,
On 6/28/18 4:51 AM, Michal Hocko wrote:
On Wed 27-06-18 10:23:39, Yang Shi wrote:
On 6/27/18 12:24 AM, Michal Hocko wrote:
On Tue 26-06-18 18:03:34, Yang Shi wrote:
On 6/26/18 12:43 AM, Peter Zijlstra wrote:
On Mon, Jun 25, 2018 at 05:06:23PM -0700, Yang Shi wrote:
By looking this deeper
On Wed 27-06-18 10:23:39, Yang Shi wrote:
>
>
> On 6/27/18 12:24 AM, Michal Hocko wrote:
> > On Tue 26-06-18 18:03:34, Yang Shi wrote:
> > >
> > > On 6/26/18 12:43 AM, Peter Zijlstra wrote:
> > > > On Mon, Jun 25, 2018 at 05:06:23PM -0700, Yang Shi wrote:
> > > > > By looking this deeper, we may
On 6/27/18 12:24 AM, Michal Hocko wrote:
On Tue 26-06-18 18:03:34, Yang Shi wrote:
On 6/26/18 12:43 AM, Peter Zijlstra wrote:
On Mon, Jun 25, 2018 at 05:06:23PM -0700, Yang Shi wrote:
By looking this deeper, we may not be able to cover all the unmapping range
for VM_DEAD, for example, if t
On Tue 26-06-18 18:03:34, Yang Shi wrote:
>
>
> On 6/26/18 12:43 AM, Peter Zijlstra wrote:
> > On Mon, Jun 25, 2018 at 05:06:23PM -0700, Yang Shi wrote:
> > > By looking this deeper, we may not be able to cover all the unmapping
> > > range
> > > for VM_DEAD, for example, if the start addr is in
On 6/26/18 12:43 AM, Peter Zijlstra wrote:
On Mon, Jun 25, 2018 at 05:06:23PM -0700, Yang Shi wrote:
By looking this deeper, we may not be able to cover all the unmapping range
for VM_DEAD, for example, if the start addr is in the middle of a vma. We
can't set VM_DEAD to that vma since that w
On Mon, Jun 25, 2018 at 05:06:23PM -0700, Yang Shi wrote:
> By looking this deeper, we may not be able to cover all the unmapping range
> for VM_DEAD, for example, if the start addr is in the middle of a vma. We
> can't set VM_DEAD to that vma since that would trigger SIGSEGV for still
> mapped are
On 6/20/18 12:18 AM, Michal Hocko wrote:
On Tue 19-06-18 17:31:27, Nadav Amit wrote:
at 4:08 PM, Yang Shi wrote:
On 6/19/18 3:17 PM, Nadav Amit wrote:
at 4:34 PM, Yang Shi
wrote:
When running some mmap/munmap scalability tests with large memory (i.e.
300GB), the below hung task i
On Fri 22-06-18 18:01:08, Yang Shi wrote:
> Yes, this is true but I guess what Yang Shi meant was that an userspace
> > > access racing with munmap is not well defined. You never know whether
> > > you get your data, #PTF or SEGV because it depends on timing. The user
> > > visible change might be
Yes, this is true but I guess what Yang Shi meant was that an userspace
access racing with munmap is not well defined. You never know whether
you get your data, #PTF or SEGV because it depends on timing. The user
visible change might be that you lose content and get zero page instead
if you hit t
On 6/20/18 12:18 AM, Michal Hocko wrote:
On Tue 19-06-18 17:31:27, Nadav Amit wrote:
at 4:08 PM, Yang Shi wrote:
On 6/19/18 3:17 PM, Nadav Amit wrote:
at 4:34 PM, Yang Shi
wrote:
When running some mmap/munmap scalability tests with large memory (i.e.
300GB), the below hung task i
at 12:18 AM, Michal Hocko wrote:
> On Tue 19-06-18 17:31:27, Nadav Amit wrote:
>> at 4:08 PM, Yang Shi wrote:
>>
>>> On 6/19/18 3:17 PM, Nadav Amit wrote:
at 4:34 PM, Yang Shi
wrote:
> When running some mmap/munmap scalability tests with large memory (i.e.
>
On 6/20/18 12:17 AM, Michal Hocko wrote:
On Tue 19-06-18 14:13:05, Yang Shi wrote:
On 6/19/18 3:02 AM, Peter Zijlstra wrote:
[...]
Hold up, two things: you having to copy most of do_munmap() didn't seem
to suggest a helper function? And second, since when are we allowed to
Yes, they will
On Tue 19-06-18 17:31:27, Nadav Amit wrote:
> at 4:08 PM, Yang Shi wrote:
>
> >
> >
> > On 6/19/18 3:17 PM, Nadav Amit wrote:
> >> at 4:34 PM, Yang Shi
> >> wrote:
> >>
> >>
> >>> When running some mmap/munmap scalability tests with large memory (i.e.
> >>>
> 300GB), the below hung ta
On Tue 19-06-18 14:13:05, Yang Shi wrote:
>
>
> On 6/19/18 3:02 AM, Peter Zijlstra wrote:
[...]
> > Hold up, two things: you having to copy most of do_munmap() didn't seem
> > to suggest a helper function? And second, since when are we allowed to
>
> Yes, they will be extracted into a helper fun
at 4:08 PM, Yang Shi wrote:
>
>
> On 6/19/18 3:17 PM, Nadav Amit wrote:
>> at 4:34 PM, Yang Shi
>> wrote:
>>
>>
>>> When running some mmap/munmap scalability tests with large memory (i.e.
>>>
300GB), the below hung task issue may happen occasionally.
>>> INFO: task ps:14018 bloc
at 4:34 PM, Yang Shi wrote:
> When running some mmap/munmap scalability tests with large memory (i.e.
>> 300GB), the below hung task issue may happen occasionally.
>
> INFO: task ps:14018 blocked for more than 120 seconds.
> Tainted: GE 4.9.79-009.ali3000.alios7.x86_64 #1
> "ec
On 6/19/18 3:02 AM, Peter Zijlstra wrote:
On Tue, Jun 19, 2018 at 07:34:16AM +0800, Yang Shi wrote:
diff --git a/mm/mmap.c b/mm/mmap.c
index fc41c05..e84f80c 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2686,6 +2686,141 @@ int split_vma(struct mm_struct *mm, struct
vm_area_struct *vma,
On Tue, Jun 19, 2018 at 07:34:16AM +0800, Yang Shi wrote:
> diff --git a/mm/mmap.c b/mm/mmap.c
> index fc41c05..e84f80c 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -2686,6 +2686,141 @@ int split_vma(struct mm_struct *mm, struct
> vm_area_struct *vma,
> return __split_vma(mm, vma, addr,
When running some mmap/munmap scalability tests with large memory (i.e.
> 300GB), the below hung task issue may happen occasionally.
INFO: task ps:14018 blocked for more than 120 seconds.
Tainted: GE 4.9.79-009.ali3000.alios7.x86_64 #1
"echo 0 > /proc/sys/kernel/hung_task_timeo
24 matches
Mail list logo