Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Content-Type: text/plain;
        charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
Subject: Re: [failures] mm-vmscan-remove-unnecessary-lruvec-adding.patch
 removed from -mm tree
From:   Qian Cai <cai@lca.pw>
In-Reply-To: <f37b9b6b-730b-09b0-dd6b-5acba53e71e6@linux.alibaba.com>
Date:   Fri, 6 Mar 2020 21:27:41 -0500
Cc:     LKML <linux-kernel@vger.kernel.org>,
        Andrew Morton <akpm@linux-foundation.org>, aarcange@redhat.com,
        daniel.m.jordan@oracle.com, hannes@cmpxchg.org, hughd@google.com,
        khlebnikov@yandex-team.ru, kirill@shutemov.name,
        kravetz@us.ibm.com, mhocko@kernel.org, mm-commits@vger.kernel.org,
        tj@kernel.org, vdavydov.dev@gmail.com, willy@infradead.org,
        yang.shi@linux.alibaba.com
Content-Transfer-Encoding: quoted-printable
Message-Id: <792CE873-A64B-4FA6-A258-A8B6B951E698@lca.pw>
References: <20200306025041.rERhvnYmB%akpm@linux-foundation.org>
 <211632B1-2D6F-4BFA-A5A0-3030339D3D2A@lca.pw>
 <b123f1d8-eab0-4689-9400-ba1f853728b7@linux.alibaba.com>
 <f37b9b6b-730b-09b0-dd6b-5acba53e71e6@linux.alibaba.com>
To:     Alex Shi <alex.shi@linux.alibaba.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On Mar 6, 2020, at 6:58 AM, Alex Shi <alex.shi@linux.alibaba.com> =
wrote:
>=20
>=20
>=20
> =E5=9C=A8 2020/3/6 =E4=B8=8B=E5=8D=885:04, Alex Shi =E5=86=99=E9=81=93:
>>=20
>>=20
>> =E5=9C=A8 2020/3/6 =E4=B8=8A=E5=8D=8811:32, Qian Cai =E5=86=99=E9=81=93=
:
>>>=20
>>>> On Mar 5, 2020, at 9:50 PM, akpm@linux-foundation.org wrote:
>>>>=20
>>>>=20
>>>> The patch titled
>>>>    Subject: mm/vmscan: remove unnecessary lruvec adding
>>>> has been removed from the -mm tree.  Its filename was
>>>>    mm-vmscan-remove-unnecessary-lruvec-adding.patch
>>>>=20
>>>> This patch was dropped because it had testing failures
>>> Andrew, do you have more information about this failure? I hit a bug
>>> here under memory pressure and am wondering if this is related
>>> which might save me some time digging=E2=80=A6
>>>=20
>>> [ 4389.727184][ T6600] mem_cgroup_update_lru_size(00000000bb31aaed, =
0, -7): lru_size -1
>>=20
>> This bug seems failed due to a update_lru_size() missing or misplace, =
but
>> what's I changed on this patch seems unlike to cause this bug.
>>=20
>> Anyway, Qian, could you do me a favor to remove this patch and try =
again?
>=20
> Compare to this patch's change, the 'c8cba0cc2a80 mm/thp: narrow lru =
locking' is more
> likely bad. Maybe it's due to lru unlock was moved before =
ClearPageCompound() from
> before remap_page(head); guess this unlock should be move after =
ClearPageCompound or
> move back to origin place.

I can only confirmed that after reverted those 6 patches, I am no long =
be able to reproduce it.

>=20
> But I still can not reproduce this bug. Awkward!
>=20
> Alex
>=20
> ---
> line 2605 mm/huge_memory.c:
>        spin_unlock_irqrestore(&pgdat->lru_lock, flags);
>=20
>        ClearPageCompound(head);
>=20
>        split_page_owner(head, HPAGE_PMD_ORDER);
>=20
>        /* See comment in __split_huge_page_tail() */
>        if (PageAnon(head)) {
>                /* Additional pin to swap cache */
>                if (PageSwapCache(head)) {
>                        page_ref_add(head, 2);
>                        xa_unlock(&swap_cache->i_pages);
>                } else {
>                        page_ref_inc(head);
>                }
>        } else {
>                /* Additional pin to page cache */
>                page_ref_add(head, 2);
>                xa_unlock(&head->mapping->i_pages);
>        }
>=20
>        remap_page(head);