All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicholas Piggin <npiggin@gmail.com>
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>
Subject: Re: [PATCH v12 13/14] mm/vmalloc: Hugepage vmalloc mappings
Date: Fri, 19 Feb 2021 17:45:52 +1000	[thread overview]
Message-ID: <1613720396.pnvmwaa8om.astroid@bobo.none> (raw)
In-Reply-To: <e18ef38c-ecef-b15c-29b1-bd4acf0e7fe5@huawei.com>

Excerpts from Ding Tianhong's message of February 19, 2021 1:45 pm:
> Hi Nicholas:
> 
> I met some problem for this patch, like this:
> 
> kva = vmalloc(3*1024k);
> 
> remap_vmalloc_range(xxx, kva, xxx)
> 
> 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 
have a particular driver that does this?

> I think some guys really don't get used to the changes for the vmalloc that 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 
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 
code that accounts things as small pages and you can't assume large or 
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 
large in userspace as well. That takes more work but if something
really needs that for performance, it could be done.

Thanks,
Nick

WARNING: multiple messages have this Message-ID (diff)
From: Nicholas Piggin <npiggin@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>,
	Ding Tianhong <dingtianhong@huawei.com>,
	linux-mm@kvack.org
Cc: linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org,
	Christoph Hellwig <hch@infradead.org>,
	Jonathan Cameron <Jonathan.Cameron@Huawei.com>,
	Rick Edgecombe <rick.p.edgecombe@intel.com>,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v12 13/14] mm/vmalloc: Hugepage vmalloc mappings
Date: Fri, 19 Feb 2021 17:45:52 +1000	[thread overview]
Message-ID: <1613720396.pnvmwaa8om.astroid@bobo.none> (raw)
In-Reply-To: <e18ef38c-ecef-b15c-29b1-bd4acf0e7fe5@huawei.com>

Excerpts from Ding Tianhong's message of February 19, 2021 1:45 pm:
> Hi Nicholas:
> 
> I met some problem for this patch, like this:
> 
> kva = vmalloc(3*1024k);
> 
> remap_vmalloc_range(xxx, kva, xxx)
> 
> 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 
have a particular driver that does this?

> I think some guys really don't get used to the changes for the vmalloc that 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 
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 
code that accounts things as small pages and you can't assume large or 
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 
large in userspace as well. That takes more work but if something
really needs that for performance, it could be done.

Thanks,
Nick

  reply	other threads:[~2021-02-19  7:47 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-02 11:05 [PATCH v12 00/14] huge vmalloc mappings Nicholas Piggin
2021-02-02 11:05 ` Nicholas Piggin
2021-02-02 11:05 ` [PATCH v12 01/14] ARM: mm: add missing pud_page define to 2-level page tables Nicholas Piggin
2021-02-02 11:05   ` Nicholas Piggin
2021-02-02 11:05   ` Nicholas Piggin
2021-02-02 11:13   ` Russell King - ARM Linux admin
2021-02-02 11:13     ` Russell King - ARM Linux admin
2021-02-02 11:13     ` Russell King - ARM Linux admin
2021-02-02 11:47     ` Ding Tianhong
2021-02-02 11:47       ` Ding Tianhong
2021-02-02 11:47       ` Ding Tianhong
2021-02-02 11:48       ` Ding Tianhong
2021-02-02 11:48         ` Ding Tianhong
2021-02-02 11:48         ` Ding Tianhong
2021-02-02 12:07       ` Russell King - ARM Linux admin
2021-02-02 12:07         ` Russell King - ARM Linux admin
2021-02-02 12:07         ` Russell King - ARM Linux admin
2021-02-03  3:01     ` Nicholas Piggin
2021-02-03  3:01       ` Nicholas Piggin
2021-02-03  3:01       ` Nicholas Piggin
2021-02-02 11:05 ` [PATCH v12 02/14] mm/vmalloc: fix HUGE_VMAP regression by enabling huge pages in vmalloc_to_page Nicholas Piggin
2021-02-02 11:05   ` Nicholas Piggin
2021-02-02 11:05 ` [PATCH v12 03/14] mm: apply_to_pte_range warn and fail if a large pte is encountered Nicholas Piggin
2021-02-02 11:05   ` Nicholas Piggin
2021-02-02 11:05 ` [PATCH v12 04/14] mm/vmalloc: rename vmap_*_range vmap_pages_*_range Nicholas Piggin
2021-02-02 11:05   ` Nicholas Piggin
2021-02-02 11:05 ` [PATCH v12 05/14] mm/ioremap: rename ioremap_*_range to vmap_*_range Nicholas Piggin
2021-02-02 11:05   ` Nicholas Piggin
2021-02-02 11:05 ` [PATCH v12 06/14] mm: HUGE_VMAP arch support cleanup Nicholas Piggin
2021-02-02 11:05   ` Nicholas Piggin
2021-02-02 11:05   ` Nicholas Piggin
2021-02-02 18:21   ` kernel test robot
2021-02-02 18:21     ` kernel test robot
2021-02-02 18:21     ` kernel test robot
2021-02-02 11:05 ` [PATCH v12 07/14] powerpc: inline huge vmap supported functions Nicholas Piggin
2021-02-02 11:05   ` Nicholas Piggin
2021-02-02 11:05 ` [PATCH v12 08/14] arm64: " Nicholas Piggin
2021-02-02 11:05   ` Nicholas Piggin
2021-02-02 11:05   ` Nicholas Piggin
2021-02-02 11:05 ` [PATCH v12 09/14] x86: " Nicholas Piggin
2021-02-02 11:05   ` Nicholas Piggin
2021-02-02 11:05 ` [PATCH v12 10/14] mm/vmalloc: provide fallback arch huge vmap support functions Nicholas Piggin
2021-02-02 11:05   ` Nicholas Piggin
2021-02-02 20:53   ` kernel test robot
2021-02-02 20:53     ` kernel test robot
2021-02-02 20:53     ` kernel test robot
2021-02-02 11:05 ` [PATCH v12 11/14] mm: Move vmap_range from mm/ioremap.c to mm/vmalloc.c Nicholas Piggin
2021-02-02 11:05   ` Nicholas Piggin
2021-02-02 11:05 ` [PATCH v12 12/14] mm/vmalloc: add vmap_range_noflush variant Nicholas Piggin
2021-02-02 11:05   ` Nicholas Piggin
2021-02-02 11:05 ` [PATCH v12 13/14] mm/vmalloc: Hugepage vmalloc mappings Nicholas Piggin
2021-02-02 11:05   ` Nicholas Piggin
2021-02-19  3:45   ` Ding Tianhong
2021-02-19  3:45     ` Ding Tianhong
2021-02-19  7:45     ` Nicholas Piggin [this message]
2021-02-19  7:45       ` Nicholas Piggin
2021-02-19  8:52       ` Ding Tianhong
2021-02-19  8:52         ` Ding Tianhong
2021-02-02 11:05 ` [PATCH v12 14/14] powerpc/64s/radix: Enable huge " Nicholas Piggin
2021-02-02 11:05   ` Nicholas Piggin
2021-02-02 13:48   ` kernel test robot
2021-02-02 13:48     ` kernel test robot
2021-02-02 13:48     ` kernel test robot
2021-02-03  4:26 [PATCH v12 13/14] mm/vmalloc: Hugepage " kernel test robot

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=1613720396.pnvmwaa8om.astroid@bobo.none \
    --to=npiggin@gmail.com \
    --cc=Jonathan.Cameron@Huawei.com \
    --cc=akpm@linux-foundation.org \
    --cc=christophe.leroy@csgroup.eu \
    --cc=dingtianhong@huawei.com \
    --cc=hch@infradead.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=rick.p.edgecombe@intel.com \
    /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.