* CONFIG_PIN_TLB experiments @ 2005-05-02 20:42 Marcelo Tosatti 2005-05-03 18:14 ` Conn Clark 2005-05-03 18:47 ` Dan Malek 0 siblings, 2 replies; 7+ messages in thread From: Marcelo Tosatti @ 2005-05-02 20:42 UTC (permalink / raw) To: Dan Malek, linux-ppc-embedded Hi 8xx folks, I've been testing the CONFIG_PIN_TLB option under v2.6, results are not good. The 8Mbyte TLB entries do not seem to work as expected, they do not cover the regions which they claim to. Accesses inside the region covered by pinned 8Mb TLB result in pagefaults and 4kb entries getting created. Actually, CONFIG_PIN_TLB slowdowns the system, as expected (there are only 28 usable TLB's instead of 32). v2.6 CONFIG_PIN_TLB: I-TLB userspace misses: 162113 I-TLB kernel misses: 135911 D-TLB userspace misses: 289452 D-TLB kernel misses: 257039 v2.6 without CONFIG_PIN_TLB: I-TLB userspace misses: 160828 I-TLB kernel misses: 134746 D-TLB userspace misses: 253557 D-TLB kernel misses: 227383 The following BDI output shows the pinned, 8MByte data page mapping present, at 0xc0000000. BDI>rds 826 SPR 826 : 0x00007f00 32512 BDI>rms 792 0x0c001C00 BDI>rms 824 1 BDI>rds 824 SPR 824 : 0xc00000f0 -1073741584 BDI>rds 825 SPR 825 : 0x00000fe0 4064 BDI>rds 826 SPR 826 : 0x00007fff 32767 <- "0x00007fff" was 0x00007f00" initially. I tried enabling usermode access without success. There are several 4Kb mappings inside the range covered by this 8Mb TLB entry, for example: BDI>rms 792 0x0c000200 BDI>rms 824 1 BDI>rds 824 SPR 824 : 0xc0224f17 -1071493353 BDI>rds 825 SPR 825 : 0x002241e0 2245088 BDI>rds 826 SPR 826 : 0x00007f00 32512 And more, without so much detail: SPR 824 : 0xc0224f17 -1071493353 SPR 824 : 0xc01fbf17 -1071661289 SPR 824 : 0xc0246f17 -1071354089 SPR 824 : 0xc023ff17 -1071382761 SPR 824 : 0xc7e35f17 - 941400297 SPR 824 : 0xc0244f17 -1071362281 SPR 824 : 0xc023ef17 -1071386857 Note that protection (SPR 826) is exactly the same as the 8Mbyte page protection. Why is the translation mechanism rejection the pinned mappings? Dan, have you ever seen this work? Am I misunderstanding how the pinned entries are supposed to work? ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: CONFIG_PIN_TLB experiments 2005-05-02 20:42 CONFIG_PIN_TLB experiments Marcelo Tosatti @ 2005-05-03 18:14 ` Conn Clark 2005-05-04 19:22 ` Marcelo Tosatti 2005-05-03 18:47 ` Dan Malek 1 sibling, 1 reply; 7+ messages in thread From: Conn Clark @ 2005-05-03 18:14 UTC (permalink / raw) To: Marcelo Tosatti; +Cc: linuxppc-embedded Marcelo Tosatti wrote: > Hi 8xx folks, <SNIP> > > Actually, CONFIG_PIN_TLB slowdowns the system, as expected (there are only > 28 usable TLB's instead of 32). > > > v2.6 CONFIG_PIN_TLB: > I-TLB userspace misses: 162113 > I-TLB kernel misses: 135911 > D-TLB userspace misses: 289452 > D-TLB kernel misses: 257039 > > v2.6 without CONFIG_PIN_TLB: > I-TLB userspace misses: 160828 > I-TLB kernel misses: 134746 > D-TLB userspace misses: 253557 > D-TLB kernel misses: 227383 > > Considering that the TLB kernel misses are higher with tlb pinning it appears as though the pinned TLBs are not marked as valid. > The following BDI output shows the pinned, 8MByte data page mapping present, > at 0xc0000000. > > BDI>rds 826 > SPR 826 : 0x00007f00 32512 > BDI>rms 792 0x0c001C00 > BDI>rms 824 1 > BDI>rds 824 > SPR 824 : 0xc00000f0 -1073741584 > BDI>rds 825 > SPR 825 : 0x00000fe0 4064 > BDI>rds 826 > SPR 826 : 0x00007fff 32767 <- "0x00007fff" was 0x00007f00" initially. > I tried enabling usermode access without > success. > > There are several 4Kb mappings inside the range covered by this 8Mb TLB entry, > for example: > > BDI>rms 792 0x0c000200 > BDI>rms 824 1 > BDI>rds 824 > SPR 824 : 0xc0224f17 -1071493353 > BDI>rds 825 > SPR 825 : 0x002241e0 2245088 > BDI>rds 826 > SPR 826 : 0x00007f00 32512 > > And more, without so much detail: > SPR 824 : 0xc0224f17 -1071493353 > SPR 824 : 0xc01fbf17 -1071661289 > SPR 824 : 0xc0246f17 -1071354089 > SPR 824 : 0xc023ff17 -1071382761 > SPR 824 : 0xc7e35f17 - 941400297 > SPR 824 : 0xc0244f17 -1071362281 > SPR 824 : 0xc023ef17 -1071386857 > > Note that protection (SPR 826) is exactly the same as the 8Mbyte page protection. > > Why is the translation mechanism rejection the pinned mappings? > > Dan, have you ever seen this work? Am I misunderstanding how the pinned > entries are supposed to work? When you load the Mx_EPN of the pinned area is the EV bit being set? > > _______________________________________________ > Linuxppc-embedded mailing list > Linuxppc-embedded@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-embedded > -- Conn ***************************************************************** Blessed be the heretic, for he causes some to think and unites the rest against him. ***************************************************************** Conn Clark Engineering Assistant clark@esteem.com Electronic Systems Technology Inc. www.esteem.com Stock Ticker Symbol ELST ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: CONFIG_PIN_TLB experiments 2005-05-03 18:14 ` Conn Clark @ 2005-05-04 19:22 ` Marcelo Tosatti 2005-05-05 16:10 ` Dan Malek 2005-05-05 17:06 ` Conn Clark 0 siblings, 2 replies; 7+ messages in thread From: Marcelo Tosatti @ 2005-05-04 19:22 UTC (permalink / raw) To: Conn Clark; +Cc: linuxppc-embedded Hi, On Tue, May 03, 2005 at 11:14:39AM -0700, Conn Clark wrote: > Marcelo Tosatti wrote: > >Hi 8xx folks, > > <SNIP> > > > > >Actually, CONFIG_PIN_TLB slowdowns the system, as expected (there are only > >28 usable TLB's instead of 32). > > > > > >v2.6 CONFIG_PIN_TLB: > >I-TLB userspace misses: 162113 > >I-TLB kernel misses: 135911 > >D-TLB userspace misses: 289452 > >D-TLB kernel misses: 257039 > > > >v2.6 without CONFIG_PIN_TLB: > >I-TLB userspace misses: 160828 > >I-TLB kernel misses: 134746 > >D-TLB userspace misses: 253557 > >D-TLB kernel misses: 227383 > > > > > > Considering that the TLB kernel misses are higher with tlb pinning it > appears as though the pinned TLBs are not marked as valid. Yep > > >The following BDI output shows the pinned, 8MByte data page mapping > >present, > >at 0xc0000000. > > > >BDI>rds 826 > >SPR 826 : 0x00007f00 32512 > >BDI>rms 792 0x0c001C00 > >BDI>rms 824 1 > >BDI>rds 824 > >SPR 824 : 0xc00000f0 -1073741584 > >BDI>rds 825 > >SPR 825 : 0x00000fe0 4064 > >BDI>rds 826 > >SPR 826 : 0x00007fff 32767 <- "0x00007fff" was 0x00007f00" > >initially. I tried enabling > > usermode access without > > success. > > > >There are several 4Kb mappings inside the range covered by this 8Mb TLB > >entry, for example: > > > >BDI>rms 792 0x0c000200 > >BDI>rms 824 1 > >BDI>rds 824 > >SPR 824 : 0xc0224f17 -1071493353 > >BDI>rds 825 > >SPR 825 : 0x002241e0 2245088 > >BDI>rds 826 > >SPR 826 : 0x00007f00 32512 > > > >And more, without so much detail: > >SPR 824 : 0xc0224f17 -1071493353 > >SPR 824 : 0xc01fbf17 -1071661289 > >SPR 824 : 0xc0246f17 -1071354089 > >SPR 824 : 0xc023ff17 -1071382761 > >SPR 824 : 0xc7e35f17 - 941400297 > >SPR 824 : 0xc0244f17 -1071362281 > >SPR 824 : 0xc023ef17 -1071386857 > > > >Note that protection (SPR 826) is exactly the same as the 8Mbyte page > >protection. > >Why is the translation mechanism rejection the pinned mappings? > > > >Dan, have you ever seen this work? Am I misunderstanding how the pinned > >entries are supposed to work? > > When you load the Mx_EPN of the pinned area is the EV bit being set? Yep. "MD_RAM1" (SPR 826) is set: SPR 826 : 0x00007fff 32767 <- "0x00007fff" was 0x00007f00" Bits 17 and 18 are set. Their meaning is: "Change bit for DTLB entry" and "Entry valid flag" respectively. Bits 19...23 are also set, they represent supervisor access. Note that bit 23 "supervisor access type" is set: 0 is read-only, 1 is read-write. so everything looks OK here. "MD_RAM0": SPR 825 : 0x00000fe0 4064 Bits 20...26 are set. 20-22: 8Mbyte page set. 23-26: APGI (access protection group in 1's complement) set. It is zero (1111 in 1's complement). 27: guarded memory not set. "MD_CAM": SPR 824 : 0xc00000f0 -1073741584 Bits 24-27 are set. 24-26 is "page size" (111 = 8Mb) and 27 indicates "shared page" (ASID comparisong disabled). The 8Mbyte page is used at boot, from "start_here" until "MMU_init()" gets called... The manual says, section "9.3 Address Translation" "When TLB logic detects that a new effective page number (EPN) overlaps one in the TLB (when taking into account page sizes, subpage validity flags, user/supervisor state, etc. the new EPN is written and the old one is invalidated." I'm trying to boot a kernel which does not create kernel pte's from 0xc000000 till 0xc080000. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: CONFIG_PIN_TLB experiments 2005-05-04 19:22 ` Marcelo Tosatti @ 2005-05-05 16:10 ` Dan Malek 2005-05-05 17:06 ` Conn Clark 1 sibling, 0 replies; 7+ messages in thread From: Dan Malek @ 2005-05-05 16:10 UTC (permalink / raw) To: Marcelo Tosatti; +Cc: linuxppc-embedded On May 4, 2005, at 3:22 PM, Marcelo Tosatti wrote: > I'm trying to boot a kernel which does not create kernel pte's > from 0xc000000 till 0xc080000. The kernel will always (and must) create PTEs for all VM spaces, It's our choice to not use them. In the case of Pinned entries, what is supposed to happen is we load an entry that covers a large space. Since we never get a miss fault, we never look at the PTE tables to load something different. Thanks. -- Dan ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: CONFIG_PIN_TLB experiments 2005-05-04 19:22 ` Marcelo Tosatti 2005-05-05 16:10 ` Dan Malek @ 2005-05-05 17:06 ` Conn Clark 2005-05-05 14:11 ` Marcelo Tosatti 1 sibling, 1 reply; 7+ messages in thread From: Conn Clark @ 2005-05-05 17:06 UTC (permalink / raw) To: Marcelo Tosatti; +Cc: linuxppc-embedded Marcelo Tosatti wrote: > Hi, > > On Tue, May 03, 2005 at 11:14:39AM -0700, Conn Clark wrote: > >>Marcelo Tosatti wrote: >> >>>Hi 8xx folks, >> >><SNIP> >> >>>Actually, CONFIG_PIN_TLB slowdowns the system, as expected (there are only >>>28 usable TLB's instead of 32). >>> >>> >>>v2.6 CONFIG_PIN_TLB: >>>I-TLB userspace misses: 162113 >>>I-TLB kernel misses: 135911 >>>D-TLB userspace misses: 289452 >>>D-TLB kernel misses: 257039 >>> >>>v2.6 without CONFIG_PIN_TLB: >>>I-TLB userspace misses: 160828 >>>I-TLB kernel misses: 134746 >>>D-TLB userspace misses: 253557 >>>D-TLB kernel misses: 227383 >>> >>> >> >>Considering that the TLB kernel misses are higher with tlb pinning it >>appears as though the pinned TLBs are not marked as valid. > > > Yep > > >>>The following BDI output shows the pinned, 8MByte data page mapping >>>present, >>>at 0xc0000000. >>> >>>BDI>rds 826 >>>SPR 826 : 0x00007f00 32512 >>>BDI>rms 792 0x0c001C00 >>>BDI>rms 824 1 >>>BDI>rds 824 >>>SPR 824 : 0xc00000f0 -1073741584 >>>BDI>rds 825 >>>SPR 825 : 0x00000fe0 4064 >>>BDI>rds 826 >>>SPR 826 : 0x00007fff 32767 <- "0x00007fff" was 0x00007f00" >>>initially. I tried enabling >>> usermode access without >>> success. >>> >>>There are several 4Kb mappings inside the range covered by this 8Mb TLB >>>entry, for example: >>> >>>BDI>rms 792 0x0c000200 >>>BDI>rms 824 1 >>>BDI>rds 824 >>>SPR 824 : 0xc0224f17 -1071493353 >>>BDI>rds 825 >>>SPR 825 : 0x002241e0 2245088 >>>BDI>rds 826 >>>SPR 826 : 0x00007f00 32512 >>> >>>And more, without so much detail: >>>SPR 824 : 0xc0224f17 -1071493353 >>>SPR 824 : 0xc01fbf17 -1071661289 >>>SPR 824 : 0xc0246f17 -1071354089 >>>SPR 824 : 0xc023ff17 -1071382761 >>>SPR 824 : 0xc7e35f17 - 941400297 >>>SPR 824 : 0xc0244f17 -1071362281 >>>SPR 824 : 0xc023ef17 -1071386857 >>> >>>Note that protection (SPR 826) is exactly the same as the 8Mbyte page >>>protection. >>>Why is the translation mechanism rejection the pinned mappings? >>> >>>Dan, have you ever seen this work? Am I misunderstanding how the pinned >>>entries are supposed to work? >> >>When you load the Mx_EPN of the pinned area is the EV bit being set? > > > Yep. > > > "MD_RAM1" (SPR 826) is set: > > SPR 826 : 0x00007fff 32767 <- "0x00007fff" was 0x00007f00" > > Bits 17 and 18 are set. Their meaning is: "Change bit for DTLB entry" and > "Entry valid flag" respectively. > Bits 19...23 are also set, they represent supervisor access. Note that > bit 23 "supervisor access type" is set: 0 is read-only, 1 is read-write. > > so everything looks OK here. > > "MD_RAM0": > > SPR 825 : 0x00000fe0 4064 > > Bits 20...26 are set. > > 20-22: 8Mbyte page set. > 23-26: APGI (access protection group in 1's complement) set. It is > zero (1111 in 1's complement). > 27: guarded memory not set. > > "MD_CAM": > > SPR 824 : 0xc00000f0 -1073741584 > > Bits 24-27 are set. > > 24-26 is "page size" (111 = 8Mb) and 27 indicates "shared page" > (ASID comparisong disabled). > > The 8Mbyte page is used at boot, from "start_here" until "MMU_init()" > gets called... > > The manual says, section "9.3 Address Translation" > > "When TLB logic detects that a new effective page number (EPN) overlaps > one in the TLB (when taking into account page sizes, subpage validity flags, > user/supervisor state, etc. the new EPN is written and the old one is > invalidated." > > I'm trying to boot a kernel which does not create kernel pte's > from 0xc000000 till 0xc080000. > Well, looking at the sources I currently have, 2.6.8 and 2.4.27, I noticed that InstructionTLBMiss in 2.6 is missing some ifdefs that the 2.4 has that pertain to TLB pinning. Otherwise the code appears basically the same. **** begin 2.6.8 code **** InstructionTLBMiss: #ifdef CONFIG_8xx_CPU6 stw r3, 8(r0) li r3, 0x3f80 stw r3, 12(r0) lwz r3, 12(r0) #endif mtspr M_TW, r20 /* Save a couple of working registers */ mfcr r20 stw r20, 0(r0) stw r21, 4(r0) mfspr r20, SRR0 /* Get effective address of fault */ #ifdef CONFIG_8xx_CPU6 li r3, 0x3780 stw r3, 12(r0) lwz r3, 12(r0) #endif mtspr MD_EPN, r20 /* Have to use MD_EPN for walk, MI_EPN can't */ mfspr r20, M_TWB /* Get level 1 table entry address */ /* If we are faulting a kernel address, we have to use the * kernel page tables. */ andi. r21, r20, 0x0800 /* Address >= 0x80000000 */ beq 3f lis r21, swapper_pg_dir@h ori r21, r21, swapper_pg_dir@l rlwimi r20, r21, 0, 2, 19 3: lwz r21, 0(r20) /* Get the level 1 entry */ rlwinm. r20, r21,0,0,19 /* Extract page descriptor page address */ beq 2f /* If zero, don't try to find a pte */ /* We have a pte table, so load the MI_TWC with the attributes * for this "segment." */ tophys(r21,r21) ori r21,r21,1 /* Set valid bit */ #ifdef CONFIG_8xx_CPU6 li r3, 0x2b80 stw r3, 12(r0) lwz r3, 12(r0) #endif mtspr MI_TWC, r21 /* Set segment attributes */ #ifdef CONFIG_8xx_CPU6 li r3, 0x3b80 stw r3, 12(r0) lwz r3, 12(r0) #endif mtspr MD_TWC, r21 /* Load pte table base address */ mfspr r21, MD_TWC /* ....and get the pte address */ lwz r20, 0(r21) /* Get the pte */ ori r20, r20, _PAGE_ACCESSED stw r20, 0(r21) /* The Linux PTE won't go exactly into the MMU TLB. * Software indicator bits 21, 22 and 28 must be clear. * Software indicator bits 24, 25, 26, and 27 must be * set. All other Linux PTE bits control the behavior * of the MMU. */ li r21, 0x00f0 rlwimi r20, r21, 0, 24, 28 /* Set 24-27, clear 28 */ #ifdef CONFIG_8xx_CPU6 li r3, 0x2d80 stw r3, 12(r0) lwz r3, 12(r0) #endif mtspr MI_RPN, r20 /* Update TLB entry */ mfspr r20, M_TW /* Restore registers */ lwz r21, 0(r0) mtcr r21 lwz r21, 4(r0) #ifdef CONFIG_8xx_CPU6 lwz r3, 8(r0) #endif rfi 2: mfspr r20, M_TW /* Restore registers */ lwz r21, 0(r0) mtcr r21 lwz r21, 4(r0) #ifdef CONFIG_8xx_CPU6 lwz r3, 8(r0) #endif b InstructionAccess **** end 2.6.8 code **** **** begin 2.4.27 code **** InstructionTLBMiss: #ifdef CONFIG_8xx_CPU6 stw r3, 8(r0) li r3, 0x3f80 stw r3, 12(r0) lwz r3, 12(r0) #endif mtspr M_TW, r20 /* Save a couple of working registers */ #if !defined(CONFIG_PIN_TLB) || defined(CONFIG_MODULES) mfcr r20 stw r20, 0(r0) #endif stw r21, 4(r0) mfspr r20, SRR0 /* Get effective address of fault */ #ifdef CONFIG_8xx_CPU6 li r3, 0x3780 stw r3, 12(r0) lwz r3, 12(r0) #endif mtspr MD_EPN, r20 /* Have to use MD_EPN for walk, MI_EPN can't */ mfspr r20, M_TWB /* Get level 1 table entry address */ #if !defined(CONFIG_PIN_TLB) || defined(CONFIG_MODULES) /* If we are faulting a kernel address, we have to use the * kernel page tables. */ andi. r21, r20, 0x0800 /* Address >= 0x80000000 */ beq 3f lis r21, swapper_pg_dir@h ori r21, r21, swapper_pg_dir@l rlwimi r20, r21, 0, 2, 19 3: lwz r21, 0(r20) /* Get the level 1 entry */ rlwinm. r20, r21,0,0,19 /* Extract page descriptor page address */ beq 2f /* If zero, don't try to find a pte */ #else lwz r21, 0(r20) /* Get the level 1 entry */ mfcr r20 cmplwi cr0, r21, 0x0fff /* Test page descriptor page address */ bng- 2f /* If zero, don't try to find a pte */ mtcr r20 #endif /* We have a pte table, so load the MI_TWC with the attributes * for this "segment." */ tophys(r21,r21) ori r21,r21,1 /* Set valid bit */ #ifdef CONFIG_8xx_CPU6 li r3, 0x2b80 stw r3, 12(r0) lwz r3, 12(r0) #endif mtspr MI_TWC, r21 /* Set segment attributes */ #ifdef CONFIG_8xx_CPU6 li r3, 0x3b80 stw r3, 12(r0) lwz r3, 12(r0) #endif mtspr MD_TWC, r21 /* Load pte table base address */ mfspr r21, MD_TWC /* ....and get the pte address */ lwz r20, 0(r21) /* Get the pte */ ori r20, r20, _PAGE_ACCESSED stw r20, 0(r21) /* The Linux PTE won't go exactly into the MMU TLB. * Software indicator bits 21, 22 and 28 must be clear. * Software indicator bits 24, 25, 26, and 27 must be * set. All other Linux PTE bits control the behavior * of the MMU. */ li r21, 0x00f0 rlwimi r20, r21, 0, 24, 28 /* Set 24-27, clear 28 */ #ifdef CONFIG_8xx_CPU6 li r3, 0x2d80 stw r3, 12(r0) lwz r3, 12(r0) #endif mtspr MI_RPN, r20 /* Update TLB entry */ mfspr r20, M_TW /* Restore registers */ #if !defined(CONFIG_PIN_TLB) || defined(CONFIG_MODULES) lwz r21, 0(r0) mtcr r21 #endif lwz r21, 4(r0) #ifdef CONFIG_8xx_CPU6 lwz r3, 8(r0) #endif rfi 2: /* Restore registers */ #if !defined(CONFIG_PIN_TLB) || defined(CONFIG_MODULES) lwz r21, 0(r0) mtcr r21 #else mtcr r20 #endif mfspr r20, M_TW lwz r21, 4(r0) #ifdef CONFIG_8xx_CPU6 lwz r3, 8(r0) #endif b InstructionAccess **** end 2.4.27 code **** Does the current 2.6 kernel have these ifdefs in them? -- Conn ***************************************************************** Blessed be the heretic, for he causes some to think and unites the rest against him. ***************************************************************** Conn Clark Engineering Assistant clark@esteem.com Electronic Systems Technology Inc. www.esteem.com Stock Ticker Symbol ELST ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: CONFIG_PIN_TLB experiments 2005-05-05 17:06 ` Conn Clark @ 2005-05-05 14:11 ` Marcelo Tosatti 0 siblings, 0 replies; 7+ messages in thread From: Marcelo Tosatti @ 2005-05-05 14:11 UTC (permalink / raw) To: Conn Clark; +Cc: linuxppc-embedded > >>When you load the Mx_EPN of the pinned area is the EV bit being set? > > > > > >Yep. > > > > > >"MD_RAM1" (SPR 826) is set: > > > >SPR 826 : 0x00007fff 32767 <- "0x00007fff" was 0x00007f00" > > > >Bits 17 and 18 are set. Their meaning is: "Change bit for DTLB entry" and > >"Entry valid flag" respectively. > >Bits 19...23 are also set, they represent supervisor access. Note that > >bit 23 "supervisor access type" is set: 0 is read-only, 1 is read-write. > > > >so everything looks OK here. > > > >"MD_RAM0": > > > >SPR 825 : 0x00000fe0 4064 > > > >Bits 20...26 are set. > > > >20-22: 8Mbyte page set. > >23-26: APGI (access protection group in 1's complement) set. It is > >zero (1111 in 1's complement). > >27: guarded memory not set. > > > >"MD_CAM": > > > >SPR 824 : 0xc00000f0 -1073741584 > > > >Bits 24-27 are set. > > > >24-26 is "page size" (111 = 8Mb) and 27 indicates "shared page" > >(ASID comparisong disabled). > > > >The 8Mbyte page is used at boot, from "start_here" until "MMU_init()" > >gets called... > > > >The manual says, section "9.3 Address Translation" > > > >"When TLB logic detects that a new effective page number (EPN) overlaps > >one in the TLB (when taking into account page sizes, subpage validity > >flags, > >user/supervisor state, etc. the new EPN is written and the old one is > >invalidated." > > > >I'm trying to boot a kernel which does not create kernel pte's > >from 0xc000000 till 0xc080000. > > > > Well, looking at the sources I currently have, 2.6.8 and 2.4.27, I > noticed that InstructionTLBMiss in 2.6 is missing some ifdefs that the > 2.4 has that pertain to TLB pinning. Otherwise the code appears > basically the same. Hi Conn, Those changes shouldnt be pertinent... I believeCONFIG_PIN_TLB never worked on 2.4 either. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: CONFIG_PIN_TLB experiments 2005-05-02 20:42 CONFIG_PIN_TLB experiments Marcelo Tosatti 2005-05-03 18:14 ` Conn Clark @ 2005-05-03 18:47 ` Dan Malek 1 sibling, 0 replies; 7+ messages in thread From: Dan Malek @ 2005-05-03 18:47 UTC (permalink / raw) To: Marcelo Tosatti; +Cc: linux-ppc-embedded On May 2, 2005, at 4:42 PM, Marcelo Tosatti wrote: > I've been testing the CONFIG_PIN_TLB option under v2.6, results are > not good. As you pointed out before, the implementation looks incorrect, so I'll take a look at it and verify with tests. I'm currently debugging some hardware problems with a new 8xx board, when I get over that I'll look at it. Thanks. -- Dan ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2005-05-05 21:51 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2005-05-02 20:42 CONFIG_PIN_TLB experiments Marcelo Tosatti 2005-05-03 18:14 ` Conn Clark 2005-05-04 19:22 ` Marcelo Tosatti 2005-05-05 16:10 ` Dan Malek 2005-05-05 17:06 ` Conn Clark 2005-05-05 14:11 ` Marcelo Tosatti 2005-05-03 18:47 ` Dan Malek
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).