diff for duplicates of <87fuq649h4.fsf@linux.vnet.ibm.com> diff --git a/a/1.txt b/N1/1.txt index 4944dbd..ffc0b6b 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,6 +1,6 @@ christophe leroy <christophe.leroy@c-s.fr> writes: -> Le 14/08/2016 =C3=A0 16:17, Aneesh Kumar K.V a =C3=A9crit : +> Le 14/08/2016 à 16:17, Aneesh Kumar K.V a écrit : >> Christophe Leroy <christophe.leroy@c-s.fr> writes: >> >>> Today powerpc64 uses a set of pgtable_caches while powerpc32 uses @@ -17,17 +17,17 @@ christophe leroy <christophe.leroy@c-s.fr> writes: >> page size code ? > > 8xx supports two huge page sizes: 8M and 512k. -> As PGD entries points on 4M page tables, it means we are in an=20 +> As PGD entries points on 4M page tables, it means we are in an > eterogenous situation: -> 1/ when using 8M huge pages, we are in the same situation as what is=20 -> done for the BOOK3S (which supports 16M, 256M and 1G), that is several=20 +> 1/ when using 8M huge pages, we are in the same situation as what is +> done for the BOOK3S (which supports 16M, 256M and 1G), that is several > PDG entries pointing to a single PTE entry. what is done for FSL BOOK3E ? -> 2/ when using 512k huge pages, we are in the same situation as whan is=20 -> done for the BOOK3E: a PGD entry points to the hugepage table that=20 +> 2/ when using 512k huge pages, we are in the same situation as whan is +> done for the BOOK3E: a PGD entry points to the hugepage table that > handles several huge pages (in our case 8 huge pages) > @@ -38,37 +38,33 @@ So the idea here is to allocate different hugepte table based on hugepage size requested and hence the need to switch from hugpte-cache to a more generic PGT_CACHE ? -> The code from init_64 have been moved to a new file named init-common in= -=20 +> The code from init_64 have been moved to a new file named init-common in > order to be used by init_32 too. -> The code from the 64 bits .h has been copied into the 32 bits .h (indeed= -=20 -> it's been copied twice as the .h are now duplicated into nohash and=20 +> The code from the 64 bits .h has been copied into the 32 bits .h (indeed +> it's been copied twice as the .h are now duplicated into nohash and > book3s versions) That explanation made it a lot easy to follow the patch. Can we capture that in commit message too. Also Do we support hugepage with both 4k and 16K linux page size ?. I guess we do because 8xx only do a two level -linux page table ?=20 +linux page table ? > > [...] > ->>> diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpag= -e.c +>>> diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c >>> index 7372ee1..9164a77 100644 >>> --- a/arch/powerpc/mm/hugetlbpage.c >>> +++ b/arch/powerpc/mm/hugetlbpage.c ->>> @@ -68,7 +68,7 @@ static int __hugepte_alloc(struct mm_struct *mm, huge= -pd_t *hpdp, +>>> @@ -68,7 +68,7 @@ static int __hugepte_alloc(struct mm_struct *mm, hugepd_t *hpdp, >>> #ifdef CONFIG_PPC_FSL_BOOK3E >>> int i; ->>> int num_hugepd =3D 1 << (pshift - pdshift); ->>> - cachep =3D hugepte_cache; ->>> + cachep =3D PGT_CACHE(1); +>>> int num_hugepd = 1 << (pshift - pdshift); +>>> - cachep = hugepte_cache; +>>> + cachep = PGT_CACHE(1); >>> #else ->>> cachep =3D PGT_CACHE(pdshift - pshift); +>>> cachep = PGT_CACHE(pdshift - pshift); >>> #endif >> >> Can you explain the usage of PGT_CACHE(1) ? @@ -78,19 +74,17 @@ pd_t *hpdp, >> >> I still didn't quiet follow why we are replacing >> ->> - hugepte_cache =3D kmem_cache_create("hugepte-cache", sizeof(pte_t), +>> - hugepte_cache = kmem_cache_create("hugepte-cache", sizeof(pte_t), >> - HUGEPD_SHIFT_MASK + 1, 0, NULL); >> + pgtable_cache_add(1, NULL); >> > -> Euh ... Indeed I wanted something to replace hugepte_cache. But it looks= -=20 -> like it should be something like PGT_CACHE(0) for 32 bits targets having= -=20 -> 32 bits PTEs and PGT_CACHE(1) for 32 bits targets having 64 bits PTEs.=20 +> Euh ... Indeed I wanted something to replace hugepte_cache. But it looks +> like it should be something like PGT_CACHE(0) for 32 bits targets having +> 32 bits PTEs and PGT_CACHE(1) for 32 bits targets having 64 bits PTEs. > But PGT_CACHE(0) doesn't exist (yet). > -> Looking once more, that might not really be needed I think. I'll rework=20 +> Looking once more, that might not really be needed I think. I'll rework > it and see what I can achieve. > diff --git a/a/content_digest b/N1/content_digest index e711752..04e31d1 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -16,7 +16,7 @@ "b\0" "christophe leroy <christophe.leroy@c-s.fr> writes:\n" "\n" - "> Le 14/08/2016 =C3=A0 16:17, Aneesh Kumar K.V a =C3=A9crit :\n" + "> Le 14/08/2016 \303\240 16:17, Aneesh Kumar K.V a \303\251crit :\n" ">> Christophe Leroy <christophe.leroy@c-s.fr> writes:\n" ">>\n" ">>> Today powerpc64 uses a set of pgtable_caches while powerpc32 uses\n" @@ -33,17 +33,17 @@ ">> page size code ?\n" ">\n" "> 8xx supports two huge page sizes: 8M and 512k.\n" - "> As PGD entries points on 4M page tables, it means we are in an=20\n" + "> As PGD entries points on 4M page tables, it means we are in an \n" "> eterogenous situation:\n" - "> 1/ when using 8M huge pages, we are in the same situation as what is=20\n" - "> done for the BOOK3S (which supports 16M, 256M and 1G), that is several=20\n" + "> 1/ when using 8M huge pages, we are in the same situation as what is \n" + "> done for the BOOK3S (which supports 16M, 256M and 1G), that is several \n" "> PDG entries pointing to a single PTE entry.\n" "\n" "what is done for FSL BOOK3E ?\n" "\n" "\n" - "> 2/ when using 512k huge pages, we are in the same situation as whan is=20\n" - "> done for the BOOK3E: a PGD entry points to the hugepage table that=20\n" + "> 2/ when using 512k huge pages, we are in the same situation as whan is \n" + "> done for the BOOK3E: a PGD entry points to the hugepage table that \n" "> handles several huge pages (in our case 8 huge pages)\n" ">\n" "\n" @@ -54,37 +54,33 @@ "hugepage size requested and hence the need to switch from hugpte-cache\n" "to a more generic PGT_CACHE ?\n" "\n" - "> The code from init_64 have been moved to a new file named init-common in=\n" - "=20\n" + "> The code from init_64 have been moved to a new file named init-common in \n" "> order to be used by init_32 too.\n" - "> The code from the 64 bits .h has been copied into the 32 bits .h (indeed=\n" - "=20\n" - "> it's been copied twice as the .h are now duplicated into nohash and=20\n" + "> The code from the 64 bits .h has been copied into the 32 bits .h (indeed \n" + "> it's been copied twice as the .h are now duplicated into nohash and \n" "> book3s versions)\n" "\n" "\n" "That explanation made it a lot easy to follow the patch. Can we capture\n" "that in commit message too. Also Do we support hugepage with both 4k and\n" "16K linux page size ?. I guess we do because 8xx only do a two level\n" - "linux page table ?=20\n" + "linux page table ? \n" "\n" ">\n" "> [...]\n" ">\n" - ">>> diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpag=\n" - "e.c\n" + ">>> diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c\n" ">>> index 7372ee1..9164a77 100644\n" ">>> --- a/arch/powerpc/mm/hugetlbpage.c\n" ">>> +++ b/arch/powerpc/mm/hugetlbpage.c\n" - ">>> @@ -68,7 +68,7 @@ static int __hugepte_alloc(struct mm_struct *mm, huge=\n" - "pd_t *hpdp,\n" + ">>> @@ -68,7 +68,7 @@ static int __hugepte_alloc(struct mm_struct *mm, hugepd_t *hpdp,\n" ">>> #ifdef CONFIG_PPC_FSL_BOOK3E\n" ">>> \tint i;\n" - ">>> \tint num_hugepd =3D 1 << (pshift - pdshift);\n" - ">>> -\tcachep =3D hugepte_cache;\n" - ">>> +\tcachep =3D PGT_CACHE(1);\n" + ">>> \tint num_hugepd = 1 << (pshift - pdshift);\n" + ">>> -\tcachep = hugepte_cache;\n" + ">>> +\tcachep = PGT_CACHE(1);\n" ">>> #else\n" - ">>> \tcachep =3D PGT_CACHE(pdshift - pshift);\n" + ">>> \tcachep = PGT_CACHE(pdshift - pshift);\n" ">>> #endif\n" ">>\n" ">> Can you explain the usage of PGT_CACHE(1) ?\n" @@ -94,23 +90,21 @@ ">>\n" ">> I still didn't quiet follow why we are replacing\n" ">>\n" - ">> -\thugepte_cache =3D kmem_cache_create(\"hugepte-cache\", sizeof(pte_t),\n" + ">> -\thugepte_cache = kmem_cache_create(\"hugepte-cache\", sizeof(pte_t),\n" ">> -\t\t\t\t\t HUGEPD_SHIFT_MASK + 1, 0, NULL);\n" ">> +\tpgtable_cache_add(1, NULL);\n" ">>\n" ">\n" - "> Euh ... Indeed I wanted something to replace hugepte_cache. But it looks=\n" - "=20\n" - "> like it should be something like PGT_CACHE(0) for 32 bits targets having=\n" - "=20\n" - "> 32 bits PTEs and PGT_CACHE(1) for 32 bits targets having 64 bits PTEs.=20\n" + "> Euh ... Indeed I wanted something to replace hugepte_cache. But it looks \n" + "> like it should be something like PGT_CACHE(0) for 32 bits targets having \n" + "> 32 bits PTEs and PGT_CACHE(1) for 32 bits targets having 64 bits PTEs. \n" "> But PGT_CACHE(0) doesn't exist (yet).\n" ">\n" - "> Looking once more, that might not really be needed I think. I'll rework=20\n" + "> Looking once more, that might not really be needed I think. I'll rework \n" "> it and see what I can achieve.\n" ">\n" "\n" "Thanks\n" -aneesh -9949a4d7fa6f8b770ba133fb8170755fbfaf193252fef5045eb753ffe24e2a69 +390041166da300f02c0befdbc7eb4c6bcb3bb4331ba6e00e0dad68f74653c7d4
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.