| Message ID | 1400777250-17335-17-git-send-email-will.deacon@arm.com |
|---|---|
| State | New |
| Headers | show |
On 05/22/2014 09:47 AM, Will Deacon wrote: > write{b,w,l,q}_relaxed are implemented by some architectures in order to > permit memory-mapped I/O accesses with weaker barrier semantics than the > non-relaxed variants. > > This patch adds dummy macros for the read and write accessors to x86, > which simply expand to the non-relaxed variants. Note that this > strengthens the relaxed read accessors, since they are now ordered with > respect to each other by way of a compiler barrier. OK, do we want/need that compiler barrier? And you say "strengthens" - strengthens with respect to what if we didn't have them before? -hpa -- 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/
Hi Peter, On Thu, May 22, 2014 at 06:15:27PM +0100, H. Peter Anvin wrote: > On 05/22/2014 09:47 AM, Will Deacon wrote: > > write{b,w,l,q}_relaxed are implemented by some architectures in order to > > permit memory-mapped I/O accesses with weaker barrier semantics than the > > non-relaxed variants. > > > > This patch adds dummy macros for the read and write accessors to x86, > > which simply expand to the non-relaxed variants. Note that this > > strengthens the relaxed read accessors, since they are now ordered with > > respect to each other by way of a compiler barrier. > > OK, do we want/need that compiler barrier? And you say "strengthens" - > strengthens with respect to what if we didn't have them before? Actually, x86 does already implement the relaxed read accessors: #define readb_relaxed(a) __readb(a) #define readw_relaxed(a) __readw(a) #define readl_relaxed(a) __readl(a) where __read* don't have "memory" clobbers, unlike the read* implementations. I would like the relaxed accessors to be ordered with respect to each other but, looking again, that is already achieved through the use of volatile asm so I've come full circle and decided that we don't need the clobbers after all. What do you think? Will -- 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/
On 05/23/2014 07:46 AM, Will Deacon wrote: > > I would like the relaxed accessors to be ordered with respect to each other... > > What do you think? > I think "I would like" isn't a very good motivation. What are the semantics of these things supposed to be? It seems more than a bit odd to require them to be ordered with respect to each other and everything else (which is what a memory clobber does) and then call them "relaxed". -hpa -- 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/
On Fri, May 23, 2014 at 03:53:20PM +0100, H. Peter Anvin wrote: > On 05/23/2014 07:46 AM, Will Deacon wrote: > > > > I would like the relaxed accessors to be ordered with respect to each other... > > > > What do you think? > > > > I think "I would like" isn't a very good motivation. What are the > semantics of these things supposed to be? It seems more than a bit odd > to require them to be ordered with respect to each other and everything > else (which is what a memory clobber does) and then call them "relaxed". I suggested some informal semantics in the cover letter: https://lkml.org/lkml/2014/4/17/269 Basically, if we define relaxed accesses not to be ordered against anything apart from other accesses (relaxed or otherwise) to the same device, then they become a tonne cheaper on arm/arm64/powerpc. Currently we have to include expensive memory barriers in order to synchronise with accesses to DMA buffers which is rarely needed. For those requirements, I don't think we need the "memory" clobber for x86, but would appreciate your views on this. Will -- 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/
On 05/23/2014 07:57 AM, Will Deacon wrote: > On Fri, May 23, 2014 at 03:53:20PM +0100, H. Peter Anvin wrote: >> On 05/23/2014 07:46 AM, Will Deacon wrote: >>> >>> I would like the relaxed accessors to be ordered with respect to each other... >>> >>> What do you think? >>> >> >> I think "I would like" isn't a very good motivation. What are the >> semantics of these things supposed to be? It seems more than a bit odd >> to require them to be ordered with respect to each other and everything >> else (which is what a memory clobber does) and then call them "relaxed". > > I suggested some informal semantics in the cover letter: > > https://lkml.org/lkml/2014/4/17/269 > > Basically, if we define relaxed accesses not to be ordered against anything > apart from other accesses (relaxed or otherwise) to the same device, then > they become a tonne cheaper on arm/arm64/powerpc. Currently we have to > include expensive memory barriers in order to synchronise with accesses to > DMA buffers which is rarely needed. > > For those requirements, I don't think we need the "memory" clobber for x86, > but would appreciate your views on this. > OK... first of all you didn't send the cover letter to the union of all the people you sent patches to, but second, documenting semantics in the one piece of the patchset that wouldn't make it into git is just about the worst possible place to put it. This documentation is absolutely critical if we expect people to be able to use these correctly, including when additional barriers may be required. As far as x86 is concerned, in gcc volatiles are ordered with respect to each other, so as you say I don't think we need a memory clobber here. -hpa -- 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/
On Fri, May 23, 2014 at 04:20:08PM +0100, H. Peter Anvin wrote: > On 05/23/2014 07:57 AM, Will Deacon wrote: > > On Fri, May 23, 2014 at 03:53:20PM +0100, H. Peter Anvin wrote: > >> On 05/23/2014 07:46 AM, Will Deacon wrote: > >>> I would like the relaxed accessors to be ordered with respect to each other... > >>> > >>> What do you think? > >>> > >> > >> I think "I would like" isn't a very good motivation. What are the > >> semantics of these things supposed to be? It seems more than a bit odd > >> to require them to be ordered with respect to each other and everything > >> else (which is what a memory clobber does) and then call them "relaxed". > > > > I suggested some informal semantics in the cover letter: > > > > https://lkml.org/lkml/2014/4/17/269 > > > > Basically, if we define relaxed accesses not to be ordered against anything > > apart from other accesses (relaxed or otherwise) to the same device, then > > they become a tonne cheaper on arm/arm64/powerpc. Currently we have to > > include expensive memory barriers in order to synchronise with accesses to > > DMA buffers which is rarely needed. > > > > For those requirements, I don't think we need the "memory" clobber for x86, > > but would appreciate your views on this. > > > > OK... first of all you didn't send the cover letter to the union of all > the people you sent patches to, but second, documenting semantics in the > one piece of the patchset that wouldn't make it into git is just about > the worst possible place to put it. > > This documentation is absolutely critical if we expect people to be able > to use these correctly, including when additional barriers may be required. There is also a documentation patch [1] in this series but, again, I didn't CC everybody on it. Sorry, but the level of interest this sort of stuff generates amongst kernel developers is close to zero so I only included people I thought cared on CC for the entire series. I'm stuck between a rock and a hard place trying to CC interested people whilst at the same time trying to avoid spamming all the arch maintainers. I'll add you to CC if/when I post a third version. In the meantime, it's all archived on lkml and linux-arch. > As far as x86 is concerned, in gcc volatiles are ordered with respect to > each other, so as you say I don't think we need a memory clobber here. Thanks for the confirmation, I'll put that patch back like it was originally. Will [1] https://lkml.org/lkml/2014/5/22/464 -- 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/
On 05/23/2014 08:34 AM, Will Deacon wrote: > > There is also a documentation patch [1] in this series but, again, I didn't > CC everybody on it. Sorry, but the level of interest this sort of stuff > generates amongst kernel developers is close to zero so I only included > people I thought cared on CC for the entire series. I'm stuck between a rock > and a hard place trying to CC interested people whilst at the same time > trying to avoid spamming all the arch maintainers. > If you are sending me a patch, please include me on the cover letter for the patch series. You don't have to send me the entire patch series (although for something like a Documentation patch which affects x86 I would consider including the union list as well.) I think regardless of level of interest, the definition of cross-architectural operations is exactly the arch maintainers job, so it isn't really out of place to "spam" us... -hpa -- 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/
On Fri, May 23, 2014 at 08:43:01AM -0700, H. Peter Anvin wrote: > On 05/23/2014 08:34 AM, Will Deacon wrote: > > > > There is also a documentation patch [1] in this series but, again, I didn't > > CC everybody on it. Sorry, but the level of interest this sort of stuff > > generates amongst kernel developers is close to zero so I only included > > people I thought cared on CC for the entire series. I'm stuck between a rock > > and a hard place trying to CC interested people whilst at the same time > > trying to avoid spamming all the arch maintainers. > > > > If you are sending me a patch, please include me on the cover letter for > the patch series. You don't have to send me the entire patch series > (although for something like a Documentation patch which affects x86 I > would consider including the union list as well.) > > I think regardless of level of interest, the definition of > cross-architectural operations is exactly the arch maintainers job, so > it isn't really out of place to "spam" us... So the one issue I had with that, is that if one tries to send an email to all arch maintainers + linux-arch + linux-kernel, the header gets too big and vger chokes and davem slaps you. So while its possibly desirable to do big unions with 0/xx and the like, its practically infeasible.
On 05/23/2014 08:56 AM, Peter Zijlstra wrote: > On Fri, May 23, 2014 at 08:43:01AM -0700, H. Peter Anvin wrote: >> On 05/23/2014 08:34 AM, Will Deacon wrote: >>> >>> There is also a documentation patch [1] in this series but, >>> again, I didn't CC everybody on it. Sorry, but the level of >>> interest this sort of stuff generates amongst kernel developers >>> is close to zero so I only included people I thought cared on >>> CC for the entire series. I'm stuck between a rock and a hard >>> place trying to CC interested people whilst at the same time >>> trying to avoid spamming all the arch maintainers. >>> >> >> If you are sending me a patch, please include me on the cover >> letter for the patch series. You don't have to send me the >> entire patch series (although for something like a Documentation >> patch which affects x86 I would consider including the union list >> as well.) >> >> I think regardless of level of interest, the definition of >> cross-architectural operations is exactly the arch maintainers >> job, so it isn't really out of place to "spam" us... > > So the one issue I had with that, is that if one tries to send an > email to all arch maintainers + linux-arch + linux-kernel, the > header gets too big and vger chokes and davem slaps you. > > So while its possibly desirable to do big unions with 0/xx and the > like, its practically infeasible. > ... or at least requires the use of a particular advanced technology called Bcc:. Not that I like Bcc:s, mind you, but it is probably better in this case. I have no idea how smart vger is, but it would be interesting if it could ignore addresses from the MAINTAINERS list... -hpa -- 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/
On Fri, May 23, 2014 at 09:12:31AM -0700, H. Peter Anvin wrote: > > So the one issue I had with that, is that if one tries to send an > > email to all arch maintainers + linux-arch + linux-kernel, the > > header gets too big and vger chokes and davem slaps you. > > > > So while its possibly desirable to do big unions with 0/xx and the > > like, its practically infeasible. > > > > ... or at least requires the use of a particular advanced technology > called Bcc:. Not that I like Bcc:s, mind you, but it is probably > better in this case. That's actually a good idea, I'll use Bcc next time. > I have no idea how smart vger is, but it would be interesting if it > could ignore addresses from the MAINTAINERS list... I suppose we should ask davem, although if such a particular loop hole were known it might get abused and we'd all end up with more email :/
On Fri, May 23, 2014 at 5:56 PM, Peter Zijlstra <peterz@infradead.org> wrote: > So the one issue I had with that, is that if one tries to send an email > to all arch maintainers + linux-arch + linux-kernel, the header gets too > big and vger chokes and davem slaps you. The arch maintainers are (supposed to be) on linux-arch. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- 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/
On 05/23/2014 09:31 AM, Geert Uytterhoeven wrote: > On Fri, May 23, 2014 at 5:56 PM, Peter Zijlstra <peterz@infradead.org> wrote: >> So the one issue I had with that, is that if one tries to send an email >> to all arch maintainers + linux-arch + linux-kernel, the header gets too >> big and vger chokes and davem slaps you. > > The arch maintainers are (supposed to be) on linux-arch. > That doesn't mean we read it in real time like something that comes into our main inbox. The messed-up context is annoying. -hpa -- 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/
diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h index b8237d8a1e0c..56d6d43aca9b 100644 --- a/arch/x86/include/asm/io.h +++ b/arch/x86/include/asm/io.h @@ -67,13 +67,16 @@ build_mmio_write(__writeb, "b", unsigned char, "q", ) build_mmio_write(__writew, "w", unsigned short, "r", ) build_mmio_write(__writel, "l", unsigned int, "r", ) -#define readb_relaxed(a) __readb(a) -#define readw_relaxed(a) __readw(a) -#define readl_relaxed(a) __readl(a) +#define readb_relaxed(a) readb(a) +#define readw_relaxed(a) readw(a) +#define readl_relaxed(a) readl(a) #define __raw_readb __readb #define __raw_readw __readw #define __raw_readl __readl +#define writeb_relaxed(v, a) writeb(v, a) +#define writew_relaxed(v, a) writew(v, a) +#define writel_relaxed(v, a) writel(v, a) #define __raw_writeb __writeb #define __raw_writew __writew #define __raw_writel __writel @@ -86,6 +89,7 @@ build_mmio_read(readq, "q", unsigned long, "=r", :"memory") build_mmio_write(writeq, "q", unsigned long, "r", :"memory") #define readq_relaxed(a) readq(a) +#define writeq_relaxed(v, a) writeq(v, a) #define __raw_readq(a) readq(a) #define __raw_writeq(val, addr) writeq(val, addr)
write{b,w,l,q}_relaxed are implemented by some architectures in order to permit memory-mapped I/O accesses with weaker barrier semantics than the non-relaxed variants. This patch adds dummy macros for the read and write accessors to x86, which simply expand to the non-relaxed variants. Note that this strengthens the relaxed read accessors, since they are now ordered with respect to each other by way of a compiler barrier. Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Signed-off-by: Will Deacon <will.deacon@arm.com> --- arch/x86/include/asm/io.h | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-)