Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1240434 > unrolled thread
| Started by | Christophe Leroy <christophe.leroy@c-s.fr> |
|---|---|
| First post | 2015-10-06 15:40 +0200 |
| Last post | 2015-10-06 22:40 +0200 |
| Articles | 5 — 3 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [PATCH v2 01/25] powerpc/8xx: Save r3 all the time in DTLB miss handler Christophe Leroy <christophe.leroy@c-s.fr> - 2015-10-06 15:40 +0200
Re: [PATCH v2 01/25] powerpc/8xx: Save r3 all the time in DTLB miss handler Scott Wood <scottwood@freescale.com> - 2015-10-06 18:50 +0200
Re: [PATCH v2 01/25] powerpc/8xx: Save r3 all the time in DTLB miss handler Scott Wood <scottwood@freescale.com> - 2015-10-06 18:50 +0200
Re: [PATCH v2 01/25] powerpc/8xx: Save r3 all the time in DTLB miss handler Scott Wood <scottwood@freescale.com> - 2015-10-06 22:40 +0200
Re: [PATCH v2 01/25] powerpc/8xx: Save r3 all the time in DTLB miss handler christophe leroy <christophe.leroy@c-s.fr> - 2015-10-06 22:40 +0200
| From | Christophe Leroy <christophe.leroy@c-s.fr> |
|---|---|
| Date | 2015-10-06 15:40 +0200 |
| Subject | Re: [PATCH v2 01/25] powerpc/8xx: Save r3 all the time in DTLB miss handler |
| Message-ID | <qgADg-7zO-11@gated-at.bofh.it> |
Le 29/09/2015 00:07, Scott Wood a écrit : > On Tue, Sep 22, 2015 at 06:50:29PM +0200, Christophe Leroy wrote: >> We are spending between 40 and 160 cycles with a mean of 65 cycles in >> the TLB handling routines (measured with mftbl) so make it more >> simple althought it adds one instruction. >> >> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr> > Does this just make it simpler or does it make it faster? What is the > performance impact? Is the performance impact seen with or without > CONFIG_8xx_CPU6 enabled? Without it, it looks like you're adding an > mtspr/mfspr combo in order to replace one mfspr. > > The performance impact is not noticeable. Theoritically it adds 1 cycle on a mean of 65 cycles, that is 1.5%. Even in the worst case where we spend around 10% of the time in TLB handling exceptions, that represents only 0.15% of the total CPU time. So that's almost nothing. Behind the fact to get in simpler, the main reason is because I need a third register for the following patch in the set, otherwise I would spend a more time saving and restoring CR several times. Christophe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [next] | [standalone]
| From | Scott Wood <scottwood@freescale.com> |
|---|---|
| Date | 2015-10-06 18:50 +0200 |
| Message-ID | <qgDB7-3mf-9@gated-at.bofh.it> |
| In reply to | #1240434 |
On Tue, 2015-10-06 at 15:35 +0200, Christophe Leroy wrote: > Le 29/09/2015 00:07, Scott Wood a écrit : > > On Tue, Sep 22, 2015 at 06:50:29PM +0200, Christophe Leroy wrote: > > > We are spending between 40 and 160 cycles with a mean of 65 cycles in > > > the TLB handling routines (measured with mftbl) so make it more > > > simple althought it adds one instruction. > > > > > > Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr> > > Does this just make it simpler or does it make it faster? What is the > > performance impact? Is the performance impact seen with or without > > CONFIG_8xx_CPU6 enabled? Without it, it looks like you're adding an > > mtspr/mfspr combo in order to replace one mfspr. > > > > > The performance impact is not noticeable. Theoritically it adds 1 cycle > on a mean of 65 cycles, that is 1.5%. Even in the worst case where we > spend around 10% of the time in TLB handling exceptions, that represents > only 0.15% of the total CPU time. So that's almost nothing. > Behind the fact to get in simpler, the main reason is because I need a > third register for the following patch in the set, otherwise I would > spend a more time saving and restoring CR several times. If you had said in the changelog that it was because future patches would need the register to be saved, we could have avoided this exchange... Especially with large patchsets, I review the patches one at a time. Don't assume I know what's coming in patch n+1 (and especially not n+m) when I review patch n. -Scott -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Scott Wood <scottwood@freescale.com> |
|---|---|
| Date | 2015-10-06 18:50 +0200 |
| Message-ID | <qgDB8-3mf-17@gated-at.bofh.it> |
| In reply to | #1240434 |
On Tue, 2015-10-06 at 15:35 +0200, Christophe Leroy wrote: > Le 29/09/2015 00:07, Scott Wood a écrit : > > On Tue, Sep 22, 2015 at 06:50:29PM +0200, Christophe Leroy wrote: > > > We are spending between 40 and 160 cycles with a mean of 65 cycles in > > > the TLB handling routines (measured with mftbl) so make it more > > > simple althought it adds one instruction. > > > > > > Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr> > > Does this just make it simpler or does it make it faster? What is the > > performance impact? Is the performance impact seen with or without > > CONFIG_8xx_CPU6 enabled? Without it, it looks like you're adding an > > mtspr/mfspr combo in order to replace one mfspr. > > > > > The performance impact is not noticeable. Theoritically it adds 1 cycle > on a mean of 65 cycles, that is 1.5%. Even in the worst case where we > spend around 10% of the time in TLB handling exceptions, that represents > only 0.15% of the total CPU time. So that's almost nothing. > Behind the fact to get in simpler, the main reason is because I need a > third register for the following patch in the set, otherwise I would > spend a more time saving and restoring CR several times. FWIW, the added instruction is an SPR access and I doubt that's only one cycle. -Scott -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Scott Wood <scottwood@freescale.com> |
|---|---|
| Date | 2015-10-06 22:40 +0200 |
| Message-ID | <qgHbI-dA-5@gated-at.bofh.it> |
| In reply to | #1240712 |
On Tue, 2015-10-06 at 22:30 +0200, christophe leroy wrote: > Le 06/10/2015 18:46, Scott Wood a écrit : > > On Tue, 2015-10-06 at 15:35 +0200, Christophe Leroy wrote: > > > Le 29/09/2015 00:07, Scott Wood a écrit : > > > > On Tue, Sep 22, 2015 at 06:50:29PM +0200, Christophe Leroy wrote: > > > > > We are spending between 40 and 160 cycles with a mean of 65 cycles > > > > > in > > > > > the TLB handling routines (measured with mftbl) so make it more > > > > > simple althought it adds one instruction. > > > > > > > > > > Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr> > > > > Does this just make it simpler or does it make it faster? What is the > > > > performance impact? Is the performance impact seen with or without > > > > CONFIG_8xx_CPU6 enabled? Without it, it looks like you're adding an > > > > mtspr/mfspr combo in order to replace one mfspr. > > > > > > > > > > > The performance impact is not noticeable. Theoritically it adds 1 cycle > > > on a mean of 65 cycles, that is 1.5%. Even in the worst case where we > > > spend around 10% of the time in TLB handling exceptions, that represents > > > only 0.15% of the total CPU time. So that's almost nothing. > > > Behind the fact to get in simpler, the main reason is because I need a > > > third register for the following patch in the set, otherwise I would > > > spend a more time saving and restoring CR several times. > > FWIW, the added instruction is an SPR access and I doubt that's only one > > cycle. > > > > > According to the mpc885 reference manual (table 9-1), Instruction > Execution Timing for "Move to: mtspr, mtcrf, mtmsr, mcrxr except mtspr to LR > and CTR and to SPRs external to the core" is "serialize + 1 cycle". > Taking into account we preeceeding instructions are also 'mtspr', we are > already serialized, so it is only one cycle I believe. > Am I interpreting it wrong ? I don't know. The manual doesn't go into much detail about the mechanics of serialization. If it's just about "block[ing] all execution units" without any effect on fetching, decoding, etc. then maybe you're right. -Scott -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | christophe leroy <christophe.leroy@c-s.fr> |
|---|---|
| Date | 2015-10-06 22:40 +0200 |
| Message-ID | <qgHbI-dA-1@gated-at.bofh.it> |
| In reply to | #1240712 |
Le 06/10/2015 18:46, Scott Wood a écrit : > On Tue, 2015-10-06 at 15:35 +0200, Christophe Leroy wrote: >> Le 29/09/2015 00:07, Scott Wood a écrit : >>> On Tue, Sep 22, 2015 at 06:50:29PM +0200, Christophe Leroy wrote: >>>> We are spending between 40 and 160 cycles with a mean of 65 cycles in >>>> the TLB handling routines (measured with mftbl) so make it more >>>> simple althought it adds one instruction. >>>> >>>> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr> >>> Does this just make it simpler or does it make it faster? What is the >>> performance impact? Is the performance impact seen with or without >>> CONFIG_8xx_CPU6 enabled? Without it, it looks like you're adding an >>> mtspr/mfspr combo in order to replace one mfspr. >>> >>> >> The performance impact is not noticeable. Theoritically it adds 1 cycle >> on a mean of 65 cycles, that is 1.5%. Even in the worst case where we >> spend around 10% of the time in TLB handling exceptions, that represents >> only 0.15% of the total CPU time. So that's almost nothing. >> Behind the fact to get in simpler, the main reason is because I need a >> third register for the following patch in the set, otherwise I would >> spend a more time saving and restoring CR several times. > FWIW, the added instruction is an SPR access and I doubt that's only one > cycle. > > According to the mpc885 reference manual (table 9-1), Instruction Execution Timing for "Move to: mtspr, mtcrf, mtmsr, mcrxr except mtspr to LR and CTR and to SPRs external to the core" is "serialize + 1 cycle". Taking into account we preeceeding instructions are also 'mtspr', we are already serialized, so it is only one cycle I believe. Am I interpreting it wrong ? Christophe --- L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast. https://www.avast.com/antivirus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web