On 01/30/2019 07:06 PM, Tim Chen wrote:
> On 12/27/18 6:55 PM, Waiman Long wrote:
>> On 12/27/2018 08:31 PM, Wang, Kemi wrote:
>>> Hi, Waiman
>>>Did you post that patch? Let's see if it helps.
>> I did post the patch a while ago. I will need to rebase it to a new
>> baseline. Will do that in a
On 12/27/18 6:55 PM, Waiman Long wrote:
> On 12/27/2018 08:31 PM, Wang, Kemi wrote:
>> Hi, Waiman
>>Did you post that patch? Let's see if it helps.
>
> I did post the patch a while ago. I will need to rebase it to a new
> baseline. Will do that in a week or 2.
>
> -Longman
>
Waiman,
In a
rton
>> ; lduf...@linux.vnet.ibm.com; l...@01.org;
>> kirill.shute...@linux.intel.com
>> Subject: Re: [LKP] [mm] 9bc8039e71: will-it-scale.per_thread_ops -64.1%
>> regression
>>
>> On 11/05/2018 05:14 PM, Linus Torvalds wrote:
>>> On Mon, Nov 5
> ; lduf...@linux.vnet.ibm.com; l...@01.org;
> kirill.shute...@linux.intel.com
> Subject: Re: [LKP] [mm] 9bc8039e71: will-it-scale.per_thread_ops -64.1%
> regression
>
> On 11/05/2018 05:14 PM, Linus Torvalds wrote:
>> On Mon, Nov 5, 2018 at 12:12 PM Vlastimil Babka wrote:
Mailing List
; Matthew Wilcox ;
mho...@kernel.org; Colin King ; Andrew Morton
; lduf...@linux.vnet.ibm.com; l...@01.org;
kirill.shute...@linux.intel.com
Subject: Re: [LKP] [mm] 9bc8039e71: will-it-scale.per_thread_ops -64.1%
regression
On 11/05/2018 05:14 PM, Linus Torvalds wrote:
> On
On 11/05/2018 05:14 PM, Linus Torvalds wrote:
> On Mon, Nov 5, 2018 at 12:12 PM Vlastimil Babka wrote:
>> I didn't spot an obvious mistake in the patch itself, so it looks
>> like some bad interaction between scheduler and the mmap downgrade?
> I'm thinking it's RWSEM_SPIN_ON_OWNER that ends up
On 11/05/2018 05:14 PM, Linus Torvalds wrote:
> On Mon, Nov 5, 2018 at 12:12 PM Vlastimil Babka wrote:
>> I didn't spot an obvious mistake in the patch itself, so it looks
>> like some bad interaction between scheduler and the mmap downgrade?
> I'm thinking it's RWSEM_SPIN_ON_OWNER that ends up
On Mon, Nov 5, 2018 at 12:12 PM Vlastimil Babka wrote:
>
> I didn't spot an obvious mistake in the patch itself, so it looks
> like some bad interaction between scheduler and the mmap downgrade?
I'm thinking it's RWSEM_SPIN_ON_OWNER that ends up being confused by
the downgrade.
It looks like
On Mon, Nov 5, 2018 at 12:12 PM Vlastimil Babka wrote:
>
> I didn't spot an obvious mistake in the patch itself, so it looks
> like some bad interaction between scheduler and the mmap downgrade?
I'm thinking it's RWSEM_SPIN_ON_OWNER that ends up being confused by
the downgrade.
It looks like
On 11/5/18 10:35 AM, Linus Torvalds wrote:
On Mon, Nov 5, 2018 at 10:28 AM Yang Shi wrote:
Actually, the commit is mainly for optimizing the long stall time caused
by holding mmap_sem by write when unmapping or shrinking large mapping.
It downgrades write mmap_sem to read when zapping
On 11/5/18 10:35 AM, Linus Torvalds wrote:
On Mon, Nov 5, 2018 at 10:28 AM Yang Shi wrote:
Actually, the commit is mainly for optimizing the long stall time caused
by holding mmap_sem by write when unmapping or shrinking large mapping.
It downgrades write mmap_sem to read when zapping
On 11/5/18 6:50 PM, Linus Torvalds wrote:
> On Sun, Nov 4, 2018 at 9:08 PM kernel test robot
> wrote:
>>
>> FYI, we noticed a -64.1% regression of will-it-scale.per_thread_ops
>> due to commit 9bc8039e715d ("mm: brk: downgrade mmap_sem to read when
>> shrinking")
>
> Ugh. That looks pretty bad.
On 11/5/18 6:50 PM, Linus Torvalds wrote:
> On Sun, Nov 4, 2018 at 9:08 PM kernel test robot
> wrote:
>>
>> FYI, we noticed a -64.1% regression of will-it-scale.per_thread_ops
>> due to commit 9bc8039e715d ("mm: brk: downgrade mmap_sem to read when
>> shrinking")
>
> Ugh. That looks pretty bad.
On Mon, Nov 5, 2018 at 10:28 AM Yang Shi wrote:
>
> Actually, the commit is mainly for optimizing the long stall time caused
> by holding mmap_sem by write when unmapping or shrinking large mapping.
> It downgrades write mmap_sem to read when zapping pages. So, it looks
> the downgrade incurs
On Mon, Nov 5, 2018 at 10:28 AM Yang Shi wrote:
>
> Actually, the commit is mainly for optimizing the long stall time caused
> by holding mmap_sem by write when unmapping or shrinking large mapping.
> It downgrades write mmap_sem to read when zapping pages. So, it looks
> the downgrade incurs
On 11/5/18 9:50 AM, Linus Torvalds wrote:
On Sun, Nov 4, 2018 at 9:08 PM kernel test robot wrote:
FYI, we noticed a -64.1% regression of will-it-scale.per_thread_ops
due to commit 9bc8039e715d ("mm: brk: downgrade mmap_sem to read when
shrinking")
Ugh. That looks pretty bad.
in testcase:
On 11/5/18 9:50 AM, Linus Torvalds wrote:
On Sun, Nov 4, 2018 at 9:08 PM kernel test robot wrote:
FYI, we noticed a -64.1% regression of will-it-scale.per_thread_ops
due to commit 9bc8039e715d ("mm: brk: downgrade mmap_sem to read when
shrinking")
Ugh. That looks pretty bad.
in testcase:
On Sun, Nov 4, 2018 at 9:08 PM kernel test robot wrote:
>
> FYI, we noticed a -64.1% regression of will-it-scale.per_thread_ops
> due to commit 9bc8039e715d ("mm: brk: downgrade mmap_sem to read when
> shrinking")
Ugh. That looks pretty bad.
> in testcase: will-it-scale
> on test machine: 8
On Sun, Nov 4, 2018 at 9:08 PM kernel test robot wrote:
>
> FYI, we noticed a -64.1% regression of will-it-scale.per_thread_ops
> due to commit 9bc8039e715d ("mm: brk: downgrade mmap_sem to read when
> shrinking")
Ugh. That looks pretty bad.
> in testcase: will-it-scale
> on test machine: 8
19 matches
Mail list logo
