linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: Paul Mackerras <paulus@ozlabs.org>
Cc: benh@kernel.crashing.org, mpe@ellerman.id.au,
	linuxppc-dev@lists.ozlabs.org, linux-mm@kvack.org
Subject: Re: [PATCH V2 09/29] powerpc/mm: Hugetlbfs is book3s_64 and fsl_book3e (32 or 64)
Date: Tue, 16 Feb 2016 13:50:05 +0530	[thread overview]
Message-ID: <871t8df4ne.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <20160215050133.GD3797@oak.ozlabs.ibm.com>

Paul Mackerras <paulus@ozlabs.org> writes:

> On Mon, Feb 08, 2016 at 02:50:21PM +0530, Aneesh Kumar K.V wrote:
>> We move large part of fsl related code to hugetlbpage-book3e.c.
>> Only code movement. This also avoid #ifdef in the code.
>> 
>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
>
> I am wondering why you are adding #ifdef CONFIG_PPC_FSL_BOOK3E
> instances to hugetlbpage-book3e.c.  As far as I can tell from the
> Kconfig* files, we only support hugetlbfs on book3s_64 and
> fsl_book3e.  Yet it seems like we have provision for 64-bit processors
> that are neither book3s_64 nor fsl_book3e.
>
> So it seems that in this existing code:

Correct. That confused me as well. Now I am moving nonhash code as it is
to avoid any regression there. We can take it up as a cleanup if those
#ifdef can be removed. With the current Kconfig setup, that will be dead
code. 


>
>> -static int __hugepte_alloc(struct mm_struct *mm, hugepd_t *hpdp,
>> -			   unsigned long address, unsigned pdshift, unsigned pshift)
>> -{
>> -	struct kmem_cache *cachep;
>> -	pte_t *new;
>> -
>> -#ifdef CONFIG_PPC_FSL_BOOK3E
>> -	int i;
>> -	int num_hugepd = 1 << (pshift - pdshift);
>> -	cachep = hugepte_cache;
>> -#else
>> -	cachep = PGT_CACHE(pdshift - pshift);
>> -#endif
>> -
>> -	new = kmem_cache_zalloc(cachep, GFP_KERNEL|__GFP_REPEAT);
>> -
>> -	BUG_ON(pshift > HUGEPD_SHIFT_MASK);
>> -	BUG_ON((unsigned long)new & HUGEPD_SHIFT_MASK);
>> -
>> -	if (! new)
>> -		return -ENOMEM;
>> -
>> -	spin_lock(&mm->page_table_lock);
>> -#ifdef CONFIG_PPC_FSL_BOOK3E
>> -	/*
>> -	 * We have multiple higher-level entries that point to the same
>> -	 * actual pte location.  Fill in each as we go and backtrack on error.
>> -	 * We need all of these so the DTLB pgtable walk code can find the
>> -	 * right higher-level entry without knowing if it's a hugepage or not.
>> -	 */
>> -	for (i = 0; i < num_hugepd; i++, hpdp++) {
>> -		if (unlikely(!hugepd_none(*hpdp)))
>> -			break;
>> -		else
>> -			/* We use the old format for PPC_FSL_BOOK3E */
>> -			hpdp->pd = ((unsigned long)new & ~PD_HUGE) | pshift;
>> -	}
>> -	/* If we bailed from the for loop early, an error occurred, clean up */
>> -	if (i < num_hugepd) {
>> -		for (i = i - 1 ; i >= 0; i--, hpdp--)
>> -			hpdp->pd = 0;
>> -		kmem_cache_free(cachep, new);
>> -	}
>> -#else
>> -	if (!hugepd_none(*hpdp))
>> -		kmem_cache_free(cachep, new);
>> -	else {
>> -#ifdef CONFIG_PPC_BOOK3S_64
>> -		hpdp->pd = (unsigned long)new |
>> -			    (shift_to_mmu_psize(pshift) << 2);
>> -#else
>> -		hpdp->pd = ((unsigned long)new & ~PD_HUGE) | pshift;
>
> this last line here hasn't ended up anywhere and has effectively been
> deleted.  Was that deliberate?
>

Didn't get that . We do that in nonhash __hpte_alloc. Adding that here
for easy review.

	spin_lock(&mm->page_table_lock);
	/*
	 * We have multiple higher-level entries that point to the same
	 * actual pte location.  Fill in each as we go and backtrack on error.
	 * We need all of these so the DTLB pgtable walk code can find the
	 * right higher-level entry without knowing if it's a hugepage or not.
	 */
	for (i = 0; i < num_hugepd; i++, hpdp++) {
		if (unlikely(!hugepd_none(*hpdp)))
			break;
		else
			/* We use the old format for PPC_FSL_BOOK3E */
			hpdp->pd = ((unsigned long)new & ~PD_HUGE) | pshift;
	}

and the book3s 64 bit variant

	spin_lock(&mm->page_table_lock);
	if (!hugepd_none(*hpdp))
		kmem_cache_free(cachep, new);
	else {
		hpdp->pd = (unsigned long)new |
			    (shift_to_mmu_psize(pshift) << 2);
	}


-aneesh

  reply	other threads:[~2016-02-16  8:20 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-08  9:20 [PATCH V2 00/29] Book3s abstraction in preparation for new MMU model Aneesh Kumar K.V
2016-02-08  9:20 ` [PATCH V2 01/29] powerpc/mm: add _PAGE_HASHPTE similar to 4K hash Aneesh Kumar K.V
2016-02-12  2:49   ` Paul Mackerras
2016-02-13  5:08     ` Aneesh Kumar K.V
2016-02-08  9:20 ` [PATCH V2 02/29] powerpc/mm: Split pgtable types to separate header Aneesh Kumar K.V
2016-02-12  2:52   ` Paul Mackerras
2016-02-13  5:12     ` Aneesh Kumar K.V
2016-02-08  9:20 ` [PATCH V2 03/29] powerpc/mm: Switch book3s 64 with 64K page size to 4 level page table Aneesh Kumar K.V
2016-02-08  9:20 ` [PATCH V2 04/29] powerpc/mm: Copy pgalloc (part 1) Aneesh Kumar K.V
2016-02-08  9:20 ` [PATCH V2 05/29] powerpc/mm: Copy pgalloc (part 2) Aneesh Kumar K.V
2016-02-12  3:53   ` Paul Mackerras
2016-02-15  5:25     ` Aneesh Kumar K.V
2016-02-08  9:20 ` [PATCH V2 06/29] powerpc/mm: Copy pgalloc (part 3) Aneesh Kumar K.V
2016-02-08  9:20 ` [PATCH V2 07/29] mm: Make vm_get_page_prot arch specific Aneesh Kumar K.V
2016-02-15  3:21   ` Paul Mackerras
2016-02-15  4:40     ` Aneesh Kumar K.V
2016-02-08  9:20 ` [PATCH V2 08/29] mm: Some arch may want to use HPAGE_PMD related values as variables Aneesh Kumar K.V
2016-02-15  4:11   ` Paul Mackerras
2016-02-16  8:12     ` Aneesh Kumar K.V
2016-02-08  9:20 ` [PATCH V2 09/29] powerpc/mm: Hugetlbfs is book3s_64 and fsl_book3e (32 or 64) Aneesh Kumar K.V
2016-02-15  5:01   ` Paul Mackerras
2016-02-16  8:20     ` Aneesh Kumar K.V [this message]
2016-02-08  9:20 ` [PATCH V2 10/29] powerpc/mm: free_hugepd_range split to hash and nonhash Aneesh Kumar K.V
2016-02-08  9:20 ` [PATCH V2 11/29] powerpc/mm: Use helper instead of opencoding Aneesh Kumar K.V
2016-02-08  9:20 ` [PATCH V2 12/29] powerpc/mm: Move hash64 specific defintions to seperate header Aneesh Kumar K.V
2016-02-15  5:24   ` Paul Mackerras
2016-02-16  8:25     ` Aneesh Kumar K.V
2016-02-08  9:20 ` [PATCH V2 13/29] powerpc/mm: Move swap related definition ot hash64 header Aneesh Kumar K.V
2016-02-08  9:20 ` [PATCH V2 14/29] powerpc/mm: Move hash page table related functions to pgtable-hash64.c Aneesh Kumar K.V
2016-02-08  9:20 ` [PATCH V2 15/29] powerpc/mm: Rename hash specific page table bits (_PAGE* -> H_PAGE*) Aneesh Kumar K.V
2016-02-08  9:20 ` [PATCH V2 16/29] powerpc/mm: Use flush_tlb_page in ptep_clear_flush_young Aneesh Kumar K.V
2016-02-08  9:20 ` [PATCH V2 17/29] powerpc/mm: THP is only available on hash64 as of now Aneesh Kumar K.V
2016-02-08  9:20 ` [PATCH V2 18/29] powerpc/mm: Use generic version of pmdp_clear_flush_young Aneesh Kumar K.V
2016-02-08  9:20 ` [PATCH V2 19/29] powerpc/mm: Create a new headers for tlbflush for hash64 Aneesh Kumar K.V
2016-02-08  9:20 ` [PATCH V2 20/29] powerpc/mm: Hash linux abstraction for page table accessors Aneesh Kumar K.V
2016-02-08  9:20 ` [PATCH V2 21/29] powerpc/mm: Hash linux abstraction for functions in pgtable-hash.c Aneesh Kumar K.V
2016-02-08  9:20 ` [PATCH V2 22/29] powerpc/mm: Hash linux abstraction for mmu context handling code Aneesh Kumar K.V
2016-02-08  9:20 ` [PATCH V2 23/29] powerpc/mm: Move hash related mmu-*.h headers to book3s/ Aneesh Kumar K.V
2016-02-08  9:20 ` [PATCH V2 24/29] powerpc/mm: Hash linux abstractions for early init routines Aneesh Kumar K.V
2016-02-08  9:20 ` [PATCH V2 25/29] powerpc/mm: Hash linux abstraction for THP Aneesh Kumar K.V
2016-02-08  9:20 ` [PATCH V2 26/29] powerpc/mm: Hash linux abstraction for HugeTLB Aneesh Kumar K.V
2016-02-08  9:20 ` [PATCH V2 27/29] powerpc/mm: Hash linux abstraction for page table allocator Aneesh Kumar K.V
2016-02-08  9:20 ` [PATCH V2 28/29] powerpc/mm: Hash linux abstraction for tlbflush routines Aneesh Kumar K.V
2016-02-08  9:20 ` [PATCH V2 29/29] powerpc/mm: Hash linux abstraction for pte swap encoding Aneesh Kumar K.V
2016-02-09 13:22 ` [PATCH V2 00/29] Book3s abstraction in preparation for new MMU model Aneesh Kumar K.V
2016-02-23  1:59   ` Scott Wood
2016-02-23  2:17     ` Aneesh Kumar K.V
2016-02-12  4:14 ` Paul Mackerras
2016-02-13  5:15   ` Aneesh Kumar K.V
2016-02-13  8:39     ` Denis Kirjanov

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=871t8df4ne.fsf@linux.vnet.ibm.com \
    --to=aneesh.kumar@linux.vnet.ibm.com \
    --cc=benh@kernel.crashing.org \
    --cc=linux-mm@kvack.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=paulus@ozlabs.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).