| Message ID | 20230405110905.669217-1-suzuki.poulose@arm.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | arm: Do not add padding alignment for hugetlbfs backed memory | expand |
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.
On Wed, 5 Apr 2023 12:09:05 +0100, Suzuki K Poulose 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 > > [...] Applied to kvmtool (master), thanks! [1/1] arm: Do not add padding alignment for hugetlbfs backed memory https://git.kernel.org/will/kvmtool/c/77b108c6a6f1 Cheers,
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);
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(-)