All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: will@kernel.org, kvmarm@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org, alexandru.elisei@arm.com
Subject: Re: [PATCH] arm: Do not add padding alignment for hugetlbfs backed memory
Date: Wed, 05 Apr 2023 12:22:25 +0100	[thread overview]
Message-ID: <86r0syvaj2.wl-maz@kernel.org> (raw)
In-Reply-To: <20230405110905.669217-1-suzuki.poulose@arm.com>

On Wed, 05 Apr 2023 12:09:05 +0100,
Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
> 
> The arm code tries to align the memory allocation size to 2M to potentially
> make use of the transparent hugepages. But this would be problematic if we
> try to allocate from the hugetlbfs, where the allocation size could be more than
> 2M. Given we support upto 1G, let use leave it to the user to align the
> requested memory when hugetlbfs is used.
> 
> Without the patch:
>  $ echo 1 > /sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages
>  $ mount -t hugetlbfs -o pagesize=1G none /root/hugemem/
>  $  lkvm run -m 1024 --hugetlbfs /root/hugemem/  ...
>    # lkvm run -k ...  -m 1024 -c 6
>    Fatal: Can't ftruncate for mem mapping size 1075838976
> 
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> ---
>  arm/kvm.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/arm/kvm.c b/arm/kvm.c
> index d51cc15d..9f958232 100644
> --- a/arm/kvm.c
> +++ b/arm/kvm.c
> @@ -37,7 +37,9 @@ void kvm__init_ram(struct kvm *kvm)
>  	 * 2M trumps 64K, so let's go with that.
>  	 */
>  	kvm->ram_size = kvm->cfg.ram_size;
> -	kvm->arch.ram_alloc_size = kvm->ram_size + SZ_2M;
> +	kvm->arch.ram_alloc_size = kvm->ram_size;
> +	if (!kvm->cfg.hugetlbfs_path)
> +		kvm->arch.ram_alloc_size += SZ_2M;
>  	kvm->arch.ram_alloc_start = mmap_anon_or_hugetlbfs(kvm,
>  						kvm->cfg.hugetlbfs_path,
>  						kvm->arch.ram_alloc_size);

Seems sensible. For hugetlbfs, we're guaranteed that the memory is
aligned, so no need for any additional alignment (which is what this
+2MB was about).

Acked-by: Marc Zyngier <maz@kernel.org>

	M.

-- 
Without deviation from the norm, progress is not possible.

WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: will@kernel.org, kvmarm@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org, alexandru.elisei@arm.com
Subject: Re: [PATCH] arm: Do not add padding alignment for hugetlbfs backed memory
Date: Wed, 05 Apr 2023 12:22:25 +0100	[thread overview]
Message-ID: <86r0syvaj2.wl-maz@kernel.org> (raw)
In-Reply-To: <20230405110905.669217-1-suzuki.poulose@arm.com>

On Wed, 05 Apr 2023 12:09:05 +0100,
Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
> 
> The arm code tries to align the memory allocation size to 2M to potentially
> make use of the transparent hugepages. But this would be problematic if we
> try to allocate from the hugetlbfs, where the allocation size could be more than
> 2M. Given we support upto 1G, let use leave it to the user to align the
> requested memory when hugetlbfs is used.
> 
> Without the patch:
>  $ echo 1 > /sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages
>  $ mount -t hugetlbfs -o pagesize=1G none /root/hugemem/
>  $  lkvm run -m 1024 --hugetlbfs /root/hugemem/  ...
>    # lkvm run -k ...  -m 1024 -c 6
>    Fatal: Can't ftruncate for mem mapping size 1075838976
> 
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> ---
>  arm/kvm.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/arm/kvm.c b/arm/kvm.c
> index d51cc15d..9f958232 100644
> --- a/arm/kvm.c
> +++ b/arm/kvm.c
> @@ -37,7 +37,9 @@ void kvm__init_ram(struct kvm *kvm)
>  	 * 2M trumps 64K, so let's go with that.
>  	 */
>  	kvm->ram_size = kvm->cfg.ram_size;
> -	kvm->arch.ram_alloc_size = kvm->ram_size + SZ_2M;
> +	kvm->arch.ram_alloc_size = kvm->ram_size;
> +	if (!kvm->cfg.hugetlbfs_path)
> +		kvm->arch.ram_alloc_size += SZ_2M;
>  	kvm->arch.ram_alloc_start = mmap_anon_or_hugetlbfs(kvm,
>  						kvm->cfg.hugetlbfs_path,
>  						kvm->arch.ram_alloc_size);

Seems sensible. For hugetlbfs, we're guaranteed that the memory is
aligned, so no need for any additional alignment (which is what this
+2MB was about).

Acked-by: Marc Zyngier <maz@kernel.org>

	M.

-- 
Without deviation from the norm, progress is not possible.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2023-04-05 11:22 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-05 11:09 [PATCH] arm: Do not add padding alignment for hugetlbfs backed memory Suzuki K Poulose
2023-04-05 11:09 ` Suzuki K Poulose
2023-04-05 11:22 ` Marc Zyngier [this message]
2023-04-05 11:22   ` Marc Zyngier
2023-04-06 15:51 ` Will Deacon
2023-04-06 15:51   ` Will Deacon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86r0syvaj2.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=alexandru.elisei@arm.com \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=suzuki.poulose@arm.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.