Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Fri, 19 Feb 2021 17:45:52 +1000
From:   Nicholas Piggin <npiggin@gmail.com>
Subject: Re: [PATCH v12 13/14] mm/vmalloc: Hugepage vmalloc mappings
To:     Andrew Morton <akpm@linux-foundation.org>,
        Ding Tianhong <dingtianhong@huawei.com>, linux-mm@kvack.org
Cc:     Christophe Leroy <christophe.leroy@csgroup.eu>,
        Christoph Hellwig <hch@infradead.org>,
        Jonathan Cameron <Jonathan.Cameron@Huawei.com>,
        linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org,
        linuxppc-dev@lists.ozlabs.org,
        Rick Edgecombe <rick.p.edgecombe@intel.com>
References: <20210202110515.3575274-1-npiggin@gmail.com>
        <20210202110515.3575274-14-npiggin@gmail.com>
        <e18ef38c-ecef-b15c-29b1-bd4acf0e7fe5@huawei.com>
In-Reply-To: <e18ef38c-ecef-b15c-29b1-bd4acf0e7fe5@huawei.com>
MIME-Version: 1.0
Message-Id: <1613720396.pnvmwaa8om.astroid@bobo.none>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Excerpts from Ding Tianhong's message of February 19, 2021 1:45 pm:
> Hi Nicholas:
>=20
> I met some problem for this patch, like this:
>=20
> kva =3D vmalloc(3*1024k);
>=20
> remap_vmalloc_range(xxx, kva, xxx)
>=20
> It failed because that the check for page_count(page) is null so return, =
it break the some logic for current modules.
> because the new huge page is not valid for composed page.

Hey Ding, that's a good catch. How are you testing this stuff, do you=20
have a particular driver that does this?

> I think some guys really don't get used to the changes for the vmalloc th=
at the small pages was transparency to the hugepage
> when the size is bigger than the PMD_SIZE.

I think in this case vmalloc could allocate the large page as a compound
page which would solve this problem I think? (without having actually=20
tested it)

> can we think about give a new static huge page to fix it? just like use a=
 a new vmalloc_huge_xxx function to disginguish the current function,
> the user could choose to use the transparent hugepage or static hugepage =
for vmalloc.

Yeah that's a good question, there are a few things in the huge vmalloc=20
code that accounts things as small pages and you can't assume large or=20
small. If there is benefit from forcing large pages that could certainly
be added.

Interestingly, remap_vmalloc_range in theory could map the pages as=20
large in userspace as well. That takes more work but if something
really needs that for performance, it could be done.

Thanks,
Nick