Re: [PATCH 0/4] Linux Kernel Markers
Mathieu Desnoyers <[EMAIL PROTECTED]> wrote on 20/12/2006 23:52:16: > Hi, > > You will find, in the following posts, the latest revision of the Linux Kernel > Markers. Due to the need some tracing projects (LTTng, SystemTAP) has of this > kind of mechanism, it could be nice to consider it for mainstream inclusion. > > The following patches apply on 2.6.20-rc1-git7. > > Signed-off-by : Mathieu Desnoyers <[EMAIL PROTECTED]> Mathiue, FWIW I like this idea. A few years ago I implemented something similar, but that had no explicit clients. Consequently I made my hooks code more generalized than is needed in practice. I do remember that Karim reworked the LTT instrumentation to use hooks and it worked fine. You've got the same optimizations for x86 by modifying an instruction's immediate operand and thus avoiding a d-cache hit. The only real caveat is the need to avoid the unsynchronised cross modification erratum. Which means that all processors will need to issue a serializing operation before executing a Marker whose state is changed. How is that handled? One additional thing we did, which might be useful at some future point, was adding a /proc interface. We reflected the current instrumentation though /proc and gave the status of each hook. We even talked about being able to enable or disabled instrumentation by writing to /proc but I don't think we ever implemented this. It's high time we settled the issue of instrumentation. It gets my vote, Good luck! Richard - - Richard J Moore IBM Linux Technology Centre - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] Linux Kernel Markers
Mathieu Desnoyers [EMAIL PROTECTED] wrote on 20/12/2006 23:52:16: Hi, You will find, in the following posts, the latest revision of the Linux Kernel Markers. Due to the need some tracing projects (LTTng, SystemTAP) has of this kind of mechanism, it could be nice to consider it for mainstream inclusion. The following patches apply on 2.6.20-rc1-git7. Signed-off-by : Mathieu Desnoyers [EMAIL PROTECTED] Mathiue, FWIW I like this idea. A few years ago I implemented something similar, but that had no explicit clients. Consequently I made my hooks code more generalized than is needed in practice. I do remember that Karim reworked the LTT instrumentation to use hooks and it worked fine. You've got the same optimizations for x86 by modifying an instruction's immediate operand and thus avoiding a d-cache hit. The only real caveat is the need to avoid the unsynchronised cross modification erratum. Which means that all processors will need to issue a serializing operation before executing a Marker whose state is changed. How is that handled? One additional thing we did, which might be useful at some future point, was adding a /proc interface. We reflected the current instrumentation though /proc and gave the status of each hook. We even talked about being able to enable or disabled instrumentation by writing to /proc but I don't think we ever implemented this. It's high time we settled the issue of instrumentation. It gets my vote, Good luck! Richard - - Richard J Moore IBM Linux Technology Centre - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Merging relayfs?
Tom Zanussi <[EMAIL PROTECTED]> wrote on 14/07/2005 16:01:25: > The only things that are atomic are the counts of produced and > consumed buffers and these are only ever updated or read in the slow > buffer-switch path. They're atomic because if they weren't, wouldn't > it be possible for the client to read an unfinished value if the > producer was in the middle of updating it? This depends on architecture. It is possible under some architectures to see the so-called score-boarding effect when reading on one processor while writing on another when not having imposed any atomicity. From memory, I believe this might be possible with zSeries, but I'll need to check the microarchitecture docs. It's been a long time since I read them but I do recall a reference to the score-boarding effect. > ... Richard - - Richard J Moore IBM Advanced Linux Response Team - Linux Technology Centre MOBEX: 264807; Mobile (+44) (0)7739-875237 Office: (+44) (0)1962-817072 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Merging relayfs?
Tom Zanussi [EMAIL PROTECTED] wrote on 14/07/2005 16:01:25: The only things that are atomic are the counts of produced and consumed buffers and these are only ever updated or read in the slow buffer-switch path. They're atomic because if they weren't, wouldn't it be possible for the client to read an unfinished value if the producer was in the middle of updating it? This depends on architecture. It is possible under some architectures to see the so-called score-boarding effect when reading on one processor while writing on another when not having imposed any atomicity. From memory, I believe this might be possible with zSeries, but I'll need to check the microarchitecture docs. It's been a long time since I read them but I do recall a reference to the score-boarding effect. ... Richard - - Richard J Moore IBM Advanced Linux Response Team - Linux Technology Centre MOBEX: 264807; Mobile (+44) (0)7739-875237 Office: (+44) (0)1962-817072 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Module tracing.
I missed your original post. If you want some form or generic tracing in the kernel then DProbes with LTT might help. With these tools you can build tracepoints without modifying the source. You could use system.map to generate simple tracepoint definitions (having written yourself a small program to parse the map output). Richard Richard Moore - RAS Project Lead - Linux Technology Centre (ATS-PIC). http://oss.software.ibm.com/developerworks/opensource/linux Office: (+44) (0)1962-817072, Mobile: (+44) (0)7768-298183 IBM UK Ltd, MP135 Galileo Centre, Hursley Park, Winchester, SO21 2JN, UK Constantin Loizides <[EMAIL PROTECTED]> on 05/07/2001 16:38:26 Please respond to Constantin Loizides <[EMAIL PROTECTED]> To: Tom spaziani <[EMAIL PROTECTED]> cc: linux-kernel <[EMAIL PROTECTED]> Subject: Re: Kernel Module tracing. > I want this. I've been thinking about it since your original post, and I also would be very much interested in having such a great tool by hand. Please mail me any information, or code to try, thanx! > > Perhaps you should also think about a non-devfs way of doing this, I don't > know, it's a matter of taste. Here's a Rube Goldbergesque way: when the > client registers, export a dynamically allocated major number through proc > and let the user mknod a device with that major. Yes I think, that would be a great alternative, using good old /proc. Constantin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Module tracing.
I missed your original post. If you want some form or generic tracing in the kernel then DProbes with LTT might help. With these tools you can build tracepoints without modifying the source. You could use system.map to generate simple tracepoint definitions (having written yourself a small program to parse the map output). Richard Richard Moore - RAS Project Lead - Linux Technology Centre (ATS-PIC). http://oss.software.ibm.com/developerworks/opensource/linux Office: (+44) (0)1962-817072, Mobile: (+44) (0)7768-298183 IBM UK Ltd, MP135 Galileo Centre, Hursley Park, Winchester, SO21 2JN, UK Constantin Loizides [EMAIL PROTECTED] on 05/07/2001 16:38:26 Please respond to Constantin Loizides [EMAIL PROTECTED] To: Tom spaziani [EMAIL PROTECTED] cc: linux-kernel [EMAIL PROTECTED] Subject: Re: Kernel Module tracing. I want this. I've been thinking about it since your original post, and I also would be very much interested in having such a great tool by hand. Please mail me any information, or code to try, thanx! Perhaps you should also think about a non-devfs way of doing this, I don't know, it's a matter of taste. Here's a Rube Goldbergesque way: when the client registers, export a dynamically allocated major number through proc and let the user mknod a device with that major. Yes I think, that would be a great alternative, using good old /proc. Constantin - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: temperature standard - global config option?
> 59.42886726469 ±2°C is obviously ludicrous, even if that's > what my calculator gives me. I should instead write 59 ±2°C, since So, if I follow you argument then shouldn't you be writing 58 ±2°C or should it be 60 ±2°C ? Richard Moore - RAS Project Lead - Linux Technology Centre (ATS-PIC). http://oss.software.ibm.com/developerworks/opensource/linux Office: (+44) (0)1962-817072, Mobile: (+44) (0)7768-298183 IBM UK Ltd, MP135 Galileo Centre, Hursley Park, Winchester, SO21 2JN, UK - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: temperature standard - global config option?
59.42886726469 ±2°C is obviously ludicrous, even if that's what my calculator gives me. I should instead write 59 ±2°C, since So, if I follow you argument then shouldn't you be writing 58 ±2°C or should it be 60 ±2°C ? Richard Moore - RAS Project Lead - Linux Technology Centre (ATS-PIC). http://oss.software.ibm.com/developerworks/opensource/linux Office: (+44) (0)1962-817072, Mobile: (+44) (0)7768-298183 IBM UK Ltd, MP135 Galileo Centre, Hursley Park, Winchester, SO21 2JN, UK - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
