[v3,0/4] mm: add more kernel parameters to control mTHP

Message

Maíra Canal Oct. 30, 2024, 12:58 p.m. UTC

This series introduces three patches related to the kernel parameters
controlling mTHP and a fourth patch replacing `strcpy()` for `strscpy()`
in the file `mm/huge_memory.c`.

The first patch is a straightforward documentation update, correcting
the format of the kernel parameter ``thp_anon=``.

The second and third patches focus on controlling THP support for shmem
via the kernel command line. The second patch introduces a parameter to
control the global default huge page allocation policy for the internal
shmem mount. The third patch implements a parameter similar to ``thp_anon=``,
but for shmem.

The goal of these changes is to simplify the configuration of systems that
rely on mTHP support for shmem. For instance, a platform with a GPU that
benefits from huge pages may want to enable huge pages for shmem. Having
these kernel parameters streamlines the configuration process and ensures
consistency across setups.

Let me know your thoughts.

v1 -> v2: https://lore.kernel.org/linux-mm/[e-mail]/T/

* [1/3] s/fix the format/fix the doc in the commit's subject (Barry Song & David Hildenbrand)
* [1/3] Add Barry's A-b to PATCH 1/3 (Barry Song)
* [1/3] s/64KB/64K (David Hildenbrand)
* [1/3] Add David's A-b to PATCH 1/3 (David Hildenbrand)
* [2/3] Create the function `shmem_valid_huge()` to reduce code-duplication (Baolin Wang)
* [3/4] New PATCH: generalize the function `setup_thp_anon()` and add it to common file
* [4/4] Fix typo in the documentation: s/shmem_anon/thp_shmem (Barry Song)
* [4/4] Reduce code-duplication (Barry Song)

v2 -> v3: https://lore.kernel.org/linux-mm/[e-mail]/T/

* [2/4] Apply Wang's suggestion (Baolin Wang)
* [3/4] Delete PATCH 3/4 from v2 and implement ``thp_shmem=`` just like in v1 (Barry Song)
* [4/4] New PATCH: "mm: huge_memory: Use strscpy() instead of strcpy()"

Best Regards,
- Maíra

Maíra Canal (4):
  mm: fix docs for the kernel parameter ``thp_anon=``
  mm: shmem: control THP support through the kernel command line
  mm: shmem: override mTHP shmem default with a kernel parameter
  mm: huge_memory: Use strscpy() instead of strcpy()

 .../admin-guide/kernel-parameters.txt         |  19 +-
 Documentation/admin-guide/mm/transhuge.rst    |  25 ++-
 mm/huge_memory.c                              |   4 +-
 mm/shmem.c                                    | 181 +++++++++++++++---
 4 files changed, 201 insertions(+), 28 deletions(-)

Comments

Andrew Morton Oct. 30, 2024, 10:50 p.m. UTC | #1

On Wed, 30 Oct 2024 09:58:54 -0300 Maíra Canal <[e-mail]> wrote:

> The second and third patches focus on controlling THP support for shmem
> via the kernel command line. The second patch introduces a parameter to
> control the global default huge page allocation policy for the internal
> shmem mount. 

The changelogs for patches 2 and 3 both say

: By configuring ..., applications that use shmem, such as the DRM GEM objects,
: can take advantage of mTHP before it's been configured through sysfs.

There isn't a lot of info here - please explain this timing issue in
more detail.

Because the question which leaps to mind is: shouldn't the
"applications that use shmem" be changed to "configure mTHP through
sysfs" *before* "using shmem"?  Seems pretty basic.


Also, please consider my question to be a critique of the changelogs. 
If the changelogs were complete, I wouldn't need to ask any questions!

Maíra Canal Oct. 31, 2024, 11:04 a.m. UTC | #2

Hi Andrew,

On 30/10/24 19:50, Andrew Morton wrote:
> On Wed, 30 Oct 2024 09:58:54 -0300 Maíra Canal <[e-mail]> wrote:
> 
>> The second and third patches focus on controlling THP support for shmem
>> via the kernel command line. The second patch introduces a parameter to
>> control the global default huge page allocation policy for the internal
>> shmem mount.
> 
> The changelogs for patches 2 and 3 both say
> 
> : By configuring ..., applications that use shmem, such as the DRM GEM objects,
> : can take advantage of mTHP before it's been configured through sysfs.
> 
> There isn't a lot of info here - please explain this timing issue in
> more detail.
> 
> Because the question which leaps to mind is: shouldn't the
> "applications that use shmem" be changed to "configure mTHP through
> sysfs" *before* "using shmem"?  Seems pretty basic.

Sorry about that, I'll try to improve the commit messages and add more 
details.

As mentioned in the example I gave ("DRM GEM objects"), my main use is
GEM objects backed by shmem. I'd like to use Huge Pages on the GPU and I
can only do that if I have contiguous memory to back my objects.

I can't think how I can change sysfs from a DRM driver.

Best Regards,
- Maíra

> 
> 
> Also, please consider my question to be a critique of the changelogs.
> If the changelogs were complete, I wouldn't need to ask any questions!

Andrew Morton Nov. 1, 2024, 1:12 a.m. UTC | #3

On Thu, 31 Oct 2024 08:04:58 -0300 Maíra Canal <[e-mail]> wrote:

> > There isn't a lot of info here - please explain this timing issue in
> > more detail.
> > 
> > Because the question which leaps to mind is: shouldn't the
> > "applications that use shmem" be changed to "configure mTHP through
> > sysfs" *before* "using shmem"?  Seems pretty basic.
> 
> Sorry about that, I'll try to improve the commit messages and add more 
> details.
> 
> As mentioned in the example I gave ("DRM GEM objects"), my main use is
> GEM objects backed by shmem. I'd like to use Huge Pages on the GPU and I
> can only do that if I have contiguous memory to back my objects.
> 
> I can't think how I can change sysfs from a DRM driver.

So your term "applications" actually refers to in-kernel drivers?

Maíra Canal Nov. 1, 2024, 4:34 p.m. UTC | #4

Hi Andrew,

On 31/10/24 22:12, Andrew Morton wrote:
> On Thu, 31 Oct 2024 08:04:58 -0300 Maíra Canal <[e-mail]> wrote:
> 
>>> There isn't a lot of info here - please explain this timing issue in
>>> more detail.
>>>
>>> Because the question which leaps to mind is: shouldn't the
>>> "applications that use shmem" be changed to "configure mTHP through
>>> sysfs" *before* "using shmem"?  Seems pretty basic.
>>
>> Sorry about that, I'll try to improve the commit messages and add more
>> details.
>>
>> As mentioned in the example I gave ("DRM GEM objects"), my main use is
>> GEM objects backed by shmem. I'd like to use Huge Pages on the GPU and I
>> can only do that if I have contiguous memory to back my objects.
>>
>> I can't think how I can change sysfs from a DRM driver.
> 
> So your term "applications" actually refers to in-kernel drivers?

Yes, I'll make it clearer in v4. Sorry for the vague commit message.

Best Regards,
- Maíra