diff for duplicates of <87pnxbgh8b.fsf@linux.ibm.com> diff --git a/a/1.txt b/N1/1.txt index a09da22..a8ce0d2 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,8 +1,8 @@ Christophe LEROY <christophe.leroy@c-s.fr> writes: -> Le 17/09/2018 =C3=A0 11:03, Aneesh Kumar K.V a =C3=A9crit=C2=A0: +> Le 17/09/2018 à 11:03, Aneesh Kumar K.V a écrit : >> Christophe Leroy <christophe.leroy@c-s.fr> writes: ->>=20 +>> >>> Hi, >>> >>> I'm having a hard time figuring out the best way to handle the following @@ -10,18 +10,18 @@ Christophe LEROY <christophe.leroy@c-s.fr> writes: >>> >>> On the powerpc8xx, handling 16k size pages requires to have page tables >>> with 4 identical entries. ->>=20 +>> >> I assume that hugetlb page size? If so isn't that similar to FSL hugetlb >> page table layout? > > No, it is not for 16k hugepage size with a standard page size of 4k. > > Here I'm trying to handle the case of CONFIG_PPC_16K_PAGES. -> As of today, it is implemented by using the standard Linux page layout,=20 -> ie one PTE entry for each 16k page. This forbids the use the 8xx HW=20 +> As of today, it is implemented by using the standard Linux page layout, +> ie one PTE entry for each 16k page. This forbids the use the 8xx HW > assistance. > ->>=20 +>> >>> >>> Initially I was thinking about handling this by simply modifying >>> pte_index() which changing pte_t type in order to have one entry every @@ -43,14 +43,14 @@ Christophe LEROY <christophe.leroy@c-s.fr> writes: >>> @@ -181,7 +192,13 @@ static inline unsigned long pte_update(pte_t *p, >>> : "cc" ); >>> #else /* PTE_ATOMIC_UPDATES */ ->>> unsigned long old =3D pte_val(*p); ->>> - *p =3D __pte((old & ~clr) | set); ->>> + unsigned long new =3D (old & ~clr) | set; +>>> unsigned long old = pte_val(*p); +>>> - *p = __pte((old & ~clr) | set); +>>> + unsigned long new = (old & ~clr) | set; >>> + >>> +#if defined(CONFIG_PPC_8xx) && defined(CONFIG_PPC_16K_PAGES) ->>> + p->pte =3D p->pte1 =3D p->pte2 =3D p->pte3 =3D new; +>>> + p->pte = p->pte1 = p->pte2 = p->pte3 = new; >>> +#else ->>> + *p =3D __pte(new); +>>> + *p = __pte(new); >>> +#endif >>> #endif /* !PTE_ATOMIC_UPDATES */ >>> @@ -64,10 +64,9 @@ Christophe LEROY <christophe.leroy@c-s.fr> writes: >>> * cases, and 32-bit non-hash with 32-bit PTEs. >>> */ >>> +#if defined(CONFIG_PPC_8xx) && defined(CONFIG_PPC_16K_PAGES) ->>> + ptep->pte =3D ptep->pte1 =3D ptep->pte2 =3D ptep->pte3 =3D pte_= -val(pte); +>>> + ptep->pte = ptep->pte1 = ptep->pte2 = ptep->pte3 = pte_val(pte); >>> +#else ->>> *ptep =3D pte; +>>> *ptep = pte; >>> +#endif >>> >>> @@ -80,11 +79,11 @@ val(pte); >>> >>> Thanks >>> Christophe ->>=20 +>> >> Why would pte_update bother about updating all the 4 entries?. Can you >> help me understand the issue? > -> Because the 8xx HW assistance expects 4 identical entries for each 16k=20 +> Because the 8xx HW assistance expects 4 identical entries for each 16k > page, so everytime a PTE is updated the 4 entries have to be updated. > diff --git a/a/content_digest b/N1/content_digest index 45e7f7a..29d6749 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -16,9 +16,9 @@ "b\0" "Christophe LEROY <christophe.leroy@c-s.fr> writes:\n" "\n" - "> Le 17/09/2018 =C3=A0 11:03, Aneesh Kumar K.V a =C3=A9crit=C2=A0:\n" + "> Le 17/09/2018 \303\240 11:03, Aneesh Kumar K.V a \303\251crit\302\240:\n" ">> Christophe Leroy <christophe.leroy@c-s.fr> writes:\n" - ">>=20\n" + ">> \n" ">>> Hi,\n" ">>>\n" ">>> I'm having a hard time figuring out the best way to handle the following\n" @@ -26,18 +26,18 @@ ">>>\n" ">>> On the powerpc8xx, handling 16k size pages requires to have page tables\n" ">>> with 4 identical entries.\n" - ">>=20\n" + ">> \n" ">> I assume that hugetlb page size? If so isn't that similar to FSL hugetlb\n" ">> page table layout?\n" ">\n" "> No, it is not for 16k hugepage size with a standard page size of 4k.\n" ">\n" "> Here I'm trying to handle the case of CONFIG_PPC_16K_PAGES.\n" - "> As of today, it is implemented by using the standard Linux page layout,=20\n" - "> ie one PTE entry for each 16k page. This forbids the use the 8xx HW=20\n" + "> As of today, it is implemented by using the standard Linux page layout, \n" + "> ie one PTE entry for each 16k page. This forbids the use the 8xx HW \n" "> assistance.\n" ">\n" - ">>=20\n" + ">> \n" ">>>\n" ">>> Initially I was thinking about handling this by simply modifying\n" ">>> pte_index() which changing pte_t type in order to have one entry every\n" @@ -59,14 +59,14 @@ ">>> @@ -181,7 +192,13 @@ static inline unsigned long pte_update(pte_t *p,\n" ">>> : \"cc\" );\n" ">>> #else /* PTE_ATOMIC_UPDATES */\n" - ">>> unsigned long old =3D pte_val(*p);\n" - ">>> - *p =3D __pte((old & ~clr) | set);\n" - ">>> + unsigned long new =3D (old & ~clr) | set;\n" + ">>> unsigned long old = pte_val(*p);\n" + ">>> - *p = __pte((old & ~clr) | set);\n" + ">>> + unsigned long new = (old & ~clr) | set;\n" ">>> +\n" ">>> +#if defined(CONFIG_PPC_8xx) && defined(CONFIG_PPC_16K_PAGES)\n" - ">>> + p->pte =3D p->pte1 =3D p->pte2 =3D p->pte3 =3D new;\n" + ">>> + p->pte = p->pte1 = p->pte2 = p->pte3 = new;\n" ">>> +#else\n" - ">>> + *p =3D __pte(new);\n" + ">>> + *p = __pte(new);\n" ">>> +#endif\n" ">>> #endif /* !PTE_ATOMIC_UPDATES */\n" ">>>\n" @@ -80,10 +80,9 @@ ">>> * cases, and 32-bit non-hash with 32-bit PTEs.\n" ">>> */\n" ">>> +#if defined(CONFIG_PPC_8xx) && defined(CONFIG_PPC_16K_PAGES)\n" - ">>> + ptep->pte =3D ptep->pte1 =3D ptep->pte2 =3D ptep->pte3 =3D pte_=\n" - "val(pte);\n" + ">>> + ptep->pte = ptep->pte1 = ptep->pte2 = ptep->pte3 = pte_val(pte);\n" ">>> +#else\n" - ">>> *ptep =3D pte;\n" + ">>> *ptep = pte;\n" ">>> +#endif\n" ">>>\n" ">>>\n" @@ -96,11 +95,11 @@ ">>>\n" ">>> Thanks\n" ">>> Christophe\n" - ">>=20\n" + ">> \n" ">> Why would pte_update bother about updating all the 4 entries?. Can you\n" ">> help me understand the issue?\n" ">\n" - "> Because the 8xx HW assistance expects 4 identical entries for each 16k=20\n" + "> Because the 8xx HW assistance expects 4 identical entries for each 16k \n" "> page, so everytime a PTE is updated the 4 entries have to be updated.\n" ">\n" "\n" @@ -110,4 +109,4 @@ "\n" -aneesh -d305b64618819cec25b0c4a4cbcc64a756ca0e3c10ae3e355927d39afab0dab1 +fef7a84941a974cd4518da7e201fa582e6b6802dc85fe641842a092518a84fd9
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.