of what I somewhat
already sent privately. ]
--
Karim Yaghmour
CEO - Opersys inc. / www.opersys.com
http://twitter.com/karimyaghmour
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at ht
t every single ftrace
begin/exit. But possibly starting with some kind of every nth and then
drilling down as the culprit is incrementally singled-out.
--
Karim Yaghmour
CEO - Opersys inc. / www.opersys.com
http://twitter.com/karimyaghmour
--
To unsubscribe from this list: send the line "unsub
off, but I'd like to see if a divide
and conquer approach (i.e. based on ftrace) wouldn't take the guesswork
out of smart randomization. Just a hunch.
--
Karim Yaghmour
CEO - Opersys inc. / www.opersys.com
http://twitter.com/karimyaghmour
--
To unsubscribe from this list: send the line &q
away from that for
the moment.
--
Karim Yaghmour
CEO - Opersys inc. / www.opersys.com
http://twitter.com/karimyaghmour
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.ker
e taken into account.)
===
Karim Yaghmour
[EMAIL PROTECTED]
Embedded and Real-Time Linux Expert
===
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [E
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/
--
===
Karim Yaghmour
oolkit (http://www.opersys.com/LTT).
Cheers,
Karim
===
Karim Yaghmour
[EMAIL PROTECTED]
Embedded and Real-Time Linux Expert
===
-
To unsubscribe from this list: send the line
Adeos document is
welcomed to contact me.
KEEP IN MIND that the documents are only a suggested method of
doing things designed to stimulate discussion. There isn't one
line of functionnal code out there (yet).
Best regards,
Karim
===
ady
>available that would be even better. Thanx
>
> Mike
--
===
Karim Yaghmour
[EMAIL PROTECTED]
Operating System Consultant
(Linux kernel, real-time and distributed systems)
===
-
To unsubscribe from
Be aware that this code will certainly crash your machine. It
is an attempt to drive Linux into ring-one, but it is not
functionnal. You've been warned.
Feel free to join in the discussion.
Best regards,
Karim Yaghmour
Karim Yaghmour wrote:
>
> I've put up the following
ing your callbacks since the kernel
doesn't jump in your code, but in the hooks management code
first.
Best regards,
Karim
===
Karim Yaghmour
[EMAIL PROTECTED]
Operating System Cons
; in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
--
===
Karim Yaghmour
[EMAIL PROTECTED]
Operating System Consultant
(Linux kernel, real-time and distributed systems)
=
6
Syscall entry 975,040,616,827,028 494 14 SYSCALL : close; EIP :
0x0804AE41
You can find more info on this custom event logging capability on
LTT's web site at: http://www.opersys.com/LTT
You can find DProbes at:
http://oss.software.ibm.com/developer/opensource/li
unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
--
===
Karim Yaghmour
[EMAIL P
ys.com/LTT
Cheers
Karim
===
Karim Yaghmour
[EMAIL PROTECTED]
Operating System Consultant
(Linux kernel, real-time and distributed systems)
===
-
To unsubscribe from this list: send th
ibe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
--
===
Karim Yaghmour
[EMAIL PROTECTE
t;
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
--
===
Karim Yaghmour
echo "1" > /proc/sys/dev/mac_hid/mouse_button_emulation
and there's no effect. Anyone know what this is about?
Thanks.
===
Karim Yaghmour
[EMAIL PROTECTED]
Operating System Consultant
(
e in mac_hid.c. Shouldn't this be called upon from the
keyboard and mouse handlers?
=======
Karim Yaghmour
[EMAIL PROTECTED]
Operating System Consultant
(Linux kernel, rea
case 1: set_bit(index,
&list->buttons); break;
-------
Karim Yaghmour wrote:
>
> The mac_hid_mouse_emulate_buttons() in drivers/macintosh/mac_hid.c
> which takes care of emulating multiple buttons on a
erformance and architecture issues regarding LTT,
I invite the interested reader to take a look at the paper I presented last
June at the annual Usenix technical conference:
http://www.opersys.com/LTT/ltt-usenix.ps.gz
And LTT can be found at:
http://www.opersys.com/LTT/
Cheers
==
17072, Mobile: (+44) (0)7768-298183
> IBM UK Ltd, MP135 Galileo Centre, Hursley Park, Winchester, SO21 2JN, UK
--
=======
Karim Yaghmour
[EMAIL PROTECTED]
Operating System C
Thought I'd let you know that I will reply to your suggestions (which
are quite interesting by the way) ... but I need to catch up some sleep
as it's close to 7AM here in Montreal and my brains are failing ... ;)
===
w events.
This could be used by Dprobes to enable dynamically inserted probe points to
be logged within a normal trace and, thereafter, be part of trace analysis.
Does this fit your needs?
>
> Richard Moore - RAS Project Lead - Linux Technology Centre (PISC).
>
> http://oss.softw
Richard Moore - RAS Project Lead - Linux Technology Centre (PISC).
>
> 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
--
===
Karim Yag
t the "mailing
lists" section of the project's web-site for more detail.
You can find LTT at:
http://www.opersys.com/LTT
Cheers,
Karim Yaghmour
===
Karim Yaghmour
[EMAIL PROTECTED]
Embedded and Re
/LTT
Cheers,
Karim
===
Karim Yaghmour
[EMAIL PROTECTED]
Embedded and Real-Time Linux Expert
===
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
t
Ingo Molnar wrote:
> So why do your "ping flood" results show such difference? It really is
> just another type of interrupt workload and has nothing special in it.
...
> are you suggesting this is not really a benchmark but a way to test how
> well a particular system withholds against extreme
Andrew Morton wrote:
> Still, first let us get a handle on who wants relayfs now and in the future
> and for what. Then we can better decide.
We used relayfs for our series of tests on PREEMPT_RT and I-Pipe.
Specifically, we used relayfs buffers to store the timestamps for our
interrupt latency
Greg KH wrote:
> What ever happened to exporting the relayfs file ops, and just using
> debugfs as your controlling fs instead? As all of the possible users
> fall under the "debug" type of kernel feature, it makes more sense to
> confine users to that fs, right?
Actually, like we discussed the
Greg KH wrote:
> Based on the proposed users of this fs, I don't see any. What ones are
> you saying are not "debug" type operations? And yes, I consider LTT a
> "debug" type operation :)
>
> The best part of this, is it gives distros and users a consistant place
> to mount the fs, and to know
Greg KH wrote:
> The path/filename dictates how it is used, so putting relayfs type files
> in debugfs is just fine. debugfs allows any types of files to be there.
...
> New trees in / are not LSB compliant, hence the reason for writing
> securityfs to get rid of /selinux and other LSM filesystem
Tomasz Kłoczko wrote:
> *NOT using realyfs* if it is not neccessary for possibly big amout
> of feactures future KProbes IMO in this case is *fundamental*.
>
> To time where this base not requiring relayfs feactures will not be
> integrated in kernel code better IMO will be stop merging relayfs.
Roman Zippel wrote:
> The point is to design a simple and flexible relayfs layer, which means
> not every possible function has to be done in the relayfs layer, as long
> it's flexible enough to build additional functionality on top of it (for
> which it can again provide some library functions
I have a usb-attached HD that I use from time to time. When it's connected
to my desktop through a hub it works flawlessly. When connected to my Dell
D600 Laptop, however, it sometimes randomly exhibits a loud click (as if the
heads went berzerk) and the device goes unrecognized (i.e. the USB laye
Greg KH wrote:
> Ugh, you have a bad device or power supply, or aren't giving it enough
> power to drive the thing. Nothing we can do in Linux for that, sorry.
> Buy a wall-powered usb hub, that usually helps.
I have one. I naively thought I could just plug the drive directly to the
laptop witho
Tom Zanussi wrote:
> - removed the deliver() callback
> - removed the relay_commit() function
This breaks LTT. Any reason why this needed to be removed? In the end,
the code will just end up being duplicated in ltt and all other users.
IOW, this is not some potential future use, but something tha
Christoph Hellwig wrote:
> That beein said I wish LTT folks would make a little more progress so
> we could actually include it.
We're working on it. On the topic of revamping LTT, 3 different people
came up with 3 different implementations.
Following your feedback on the patch I sent a few week
Alistair John Strachan wrote:
> You can get special USB cables that link two USB ports' 5Vs together in
> parallel, which seems to help supply the necessary current; after the HD has
> spun up you can remove the second "dummy" USB connector (my laptop only has
> two USB ports and I require the
Tom Zanussi wrote:
> In userspace, the sub-buffer reading loop looks at the commit value in
> the sub-buffer, and if it matches (sub-buffer size - padding), the
> buffer has been completely written and can be saved, otherwise it's
> not yet complete and is checked again the next time around. This
Christoph Hellwig wrote:
> We're not gonna add hooks to the kernel so you can copile the same
> horrible code you had before against it out of tree. Do a sane demux
> and submit it.
If I just wanted hooks, I would have submitted a patch that did just
that, without any logging function. The code
Missing attachment herein included.
Karim
--
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || [EMAIL PROTECTED] || 1-866-677-4546
L M B E N C H 2 . 0 S U M M A R Y
Paul Rolland wrote:
>>mmap | 794us | 654us (+18%) | 822us (+4%)
>
> You mean -18%, not +18% I think.
Doh ... too many numbers flying around ... yes, -18% :)
Karim
--
Author, Speaker, Developer, Consultant
Pushing Embedded and Rea
Ingo Molnar wrote:
> yeah, they definitely have helped, and thanks for this round of testing
> too! I'll explain the recent changes to PREEMPT_RT that resulted in
> these speedups in another mail.
Great, I'm very much looking forward to it.
> Looking at your numbers i realized that the area wh
Karim Yaghmour wrote:
> I would usually like very much to entertain this further, but we've
> really busted all the time slots I had allocated to this work. So at
> this time, we really think others should start publishing results.
> After all, our results are no more authori
Can't type right anymore ...
Karim Yaghmour wrote:
> BTW, we've also released the latest very of the LRTBF we used to
version
Karim
--
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond th
Brad Tilley wrote:
> Is there an easy way to make a running kernel display how it has been
> patched from vanilla? Probably not, but I thought I'd ask.
This issue does come up every so often. If you look in the archives you
should find some info about this, including a patch if my memory is
corre
I'm wondering if anyone's ever done an analysis on the average length
of instructions in an x86-built kernel.
Googling around, I can find references claiming that the average
instruction length on x86 is anywhere from 2.7 to 3.5 bytes, but I
can't find anything studying Linux specifically.
Just
Hello Ingo,
Ingo Oeser wrote:
> Just study the output od objdump -d and average the differences
> of the first hex number in a line printed, which are followed by a ":"
Here's a script that does what I was looking for:
#!/bin/bash
# Dissassemble
objdump -d $1 -j .text > $2-dissassembled-kernel
Jan Engelhardt wrote:
> Ok, urandom was a bad example. I have my tty logger (ttyrpld.sf.net) which
> moves a lot of data (depends) to userspace. It uses a ring buffer of "fixed"
> size (set at module load time). Apart from that relayfs could use a dynamic
> sized ring buffer, I would not see an
Karim Yaghmour wrote:
> What relayfs does, and does very well, is move very large amounts of
> data out of the kernel and make them available to user-space with very
> little overhead. In the actual case of your tty logger, I've browsed
> through the code briefly, and I think
Jan Engelhardt wrote:
> Well, what about things like urandom? It also moves "a lot" of data and does
> nothing else.
Forgive my slowness today, but I don't get the angle here:
- Relayfs is not a replacement for char devices, we've never claimed it
to be.
- Urandom generates a lot of data, and u
Andi Kleen wrote:
> It's doing a complicated function call which does who knows what in
> the logging fast path (I stopped reading after some point)
> It definitely is not putc !
I was anticipating some people would have this requirement, and this
is why I introduced the ad-hoc mode. Roman aske
Tom Zanussi wrote:
> OK, makes sense to me - I'll get rid of relay_reserve and replace it
> with the simple putc write and variant.
Please don't do that. Instead, bring back the ad-hoc mode code, that's
what is was for anyway.
> You could just create and log into a separate relayfs channel, if y
Tom Zanussi wrote:
> I don't think they need to be mutually exclusive - we could keep
> relay_reserve(), but the relay_write() that's currently built on top
> of relay_reserve() would use the putc code instead. It's complicating
> the API a bit, but if it makes everyone happy...
Actually I think
Greg KH wrote:
> On Fri, Jan 28, 2005 at 01:38:22PM -0600, Tom Zanussi wrote:
>
>>+extern void * alloc_rchan_buf(unsigned long size,
>>+ struct page ***page_array,
>>+ int *page_count);
>>+extern void free_rchan_buf(void *buf,
>>+
Greg KH wrote:
> When relayfs is built into the kernel, those symbols are then global to
> the whole static kernel.
>
> Please be nice and rename them.
My pleasure :)
Karim
--
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opers
Kingsley Cheung wrote:
> To solve the problem I applied a patch similar to the one you posted
> back in July and it fixed the problem. Could we consider putting this
> patch into relayfs? Its similar to the one posted in July 2004, except
> it also moves clear_readers() before INIT_WORK in relay_
Hello Thomas,
I don't mind having a general discussion about instrumentation, but
it has to be understood that the topic is so general and means so
many different things to different people that we are unlikely to
reach any useful consensus. Believe me, it's not for the lack of
trying. More below
Hello Thomas,
In the interest of avoiding expanding the thread too thin, I'm replying to
both emails in the same time.
Thomas Gleixner wrote:
>>relayfs is a generalized buffering mechanism. Tracing is one application
>>it serves. Check out the web site: "high-speed data-relay filesystem."
>>Fanc
Hello Roman,
Roman Zippel wrote:
> On Sat, 15 Jan 2005, Karim Yaghmour wrote:
>>In addition, and this is a very important issue, quite a few
>>kernel developers mistook LTT for a kernel debugging tool, which
>>it was never meant to be. When, in fact, if you ask those who h
Hello Roman,
Roman Zippel wrote:
> It's interesting to read more about ltt's requirements, but I still think
> it's possible to leave this work to the relayfs layer.
Ok, I'm willing to play ball, but can you be a little bit more specific.
> Why not just move the ltt buffer management into rela
at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
===
Karim Yaghmour
[EMAIL PROTECTED]
Embedded and Real-Time Linux Expert
===
-
To unsubscribe from this list: send the line &q
Jan Engelhardt wrote:
> Hm? Relayfs does not support a `cat /dev/relay/AChannelName` anymore?
This was a requirement for it to be included.
Karim
--
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || [EMAIL PROTECTED]
Hello Christoph,
Christoph Hellwig wrote:
> Why would you want anything but read access?
Fine, we can put it read-only, we'll drop the "mode" field.
> I think random access is overkill. Keeping the code simple is more
> important and user-space can post-process it.
it's overkill if you're thi
Christoph Hellwig wrote:
> the lockless mode is really just loops around cmpxchg. It's spinlocks
> reinvented poorly.
I beg to differ. You have to use different spinlocks depending on
where you are:
- serving user-space
- bh-derivatives
- irq
lockless is the same primitive regardless of your cu
Hello Roman,
Roman Zippel wrote:
> It seems we first need to specify, what relayfs actually is supposed to
> be. Is it a relaying mechanism for large amount of data from kernel to
> user space or is it a general communication channel between kernel and
> user space? You have to choose one, if
Thomas Gleixner wrote:
> This implies to seperate
>
> - infrastructure
> - event registration
> - transport mechanism
Like I said in my first response: we can't be everything for everbody,
the requirements are just too broad. ISO tried it with OSI. Have a
look at net/* for the result.
Current
Thomas Gleixner wrote:
> Which is every 1.42 seconds on a 3GHz machine. I guess we don't have
> GB's of data when the 1.42 seconds elapse without an event.
My argument was about being able to browse the amount of data I was
refering to. The hearbeat thing was an asside to Roman as to the
fact tha
Thomas Gleixner wrote:
> Sorting out disabled events is the filtering you have to do in kernel
> and you should do it in the hot path or remove the unneccecary
> tracepoints at compiletime.
Do you actually read my replies or do you just grep for something
you can object to? If you care to read m
Thomas Gleixner wrote:
> Thats the point. Adding another hardwired implementation does not give
> us a possibility to solve the hardwired problem of the already available
> stuff.
Well then, like I said before, you know what you need to do:
http://www-124.ibm.com/developerworks/oss/linux/projects
Hello Roman,
Roman Zippel wrote:
> Periodically can also mean a buffer start call back from relayfs
> (although that would mean the first entry is not guaranteed) or a
> (per cpu) eventcnt from the subsystem. The amount of needed search would
> be limited. The main point is from the relayfs PO
Hello Chistoph,
Christoph Hellwig wrote:
> The thing I'm unhappy with is what the code does currently. I haven't
> looked at the code enough nor through about the problem enough to tell
> you what's the right thing to do. Knowing that will involve review of
> the architecture and serious benchm
Thomas Gleixner wrote:
> I know, what I have said. I said reduce the filtering to the absolute
> minimum and do the rest in userspace.
You keep adopting the interpretation which best suits you, taking
quotes out of context, and keep repeating things that have already
been answered. There are limi
Thomas Gleixner wrote:
> If we add another hardwired implementation then we do not have said
> benefits.
Please stop handwaving. Folks like Andrew, Christoph, Zwane, Roman,
and others actually made specific requests for changes in the code.
What makes you think you're so special that you think yo
Hello Roman,
Roman Zippel wrote:
> An additional comment about the order of events. What you're doing in
> lockless_reserve is bogus anyway. There is no single correct time to
> write into the event. By artificially synchronizing event order and event
> time you only cheat yourself. You either
Thomas Gleixner wrote:
> Provide a hook, export it and load your filters as a module, but keep
> the filters out of the mainline kernel code.
Great idea! I will do exactly that.
Thanks,
Karim
--
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Lim
Hello Roman,
Roman Zippel wrote:
> Why is so important that it's at the start of the buffer? What's wrong
> with a special event _near_ the start of a buffer?
[snip]
> What gives you the idea, that you can't do this with what I proposed?
> You can still seek freely within the data at buffer boun
Aaron Cohen wrote:
> I've got a quick question and I just want to be clear that it
> doesn't have a political agenda behind it.
:)
> Here goes, why can't LTT and/or relayfs, work similar to the way
> syslog does and just fill a buffer (aka ring-buffer or whatever is
> appropriate), while a use
Thomas,
Thomas Gleixner wrote:
> Yes, I did already start cleaning
>
> cat ../broken-out/ltt* | patch -p1 -R
:D
If it gives you a warm and fuzzy feeling to have the last
cheap-shot, then I'm all for it, it is of no consequence anyway.
And _please_ don't forget to answer this very email with
so
Tom Zanussi wrote:
> I have to disagree. Awhile back, if you remember, I posted a patch to
> the LTT daemon that would monitor the trace stream in real time, and
> process it using an embedded Perl interpreter, no less:
>
> http://marc.theaimsgroup.com/?l=linux-kernel&m=109405724500237&w=2
>
>
erner I'll take anything. It's always a pleasure
talking with you :)
> Karim Yaghmour wrote:
>
>>If you really want to define layers, then there are actually four
>>layers:
>>1- hooking mechanism
>>2- event definition / registration
>>3- event manag
Werner Almesberger wrote:
> - if the probe target is an instruction long enough, replace it with
>a jump or call (that's what I think the kprobes folks are working
>on. I remember for sure that they were thinking about it.)
I heard about this years ago, but I don't know that anything cam
Zach Brown wrote:
> Thoughts? I, for one, am tired of writing throw-away per-cpu tracing
> patches ;)
Have you taken a look at relayfs and ltt?
Karim
--
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || [EMAIL PROTEC
Greg KH wrote:
> Hm, how about this idea for cutting about 500 more lines from the code:
>
> Why not drop the "fs" part of relayfs and just make the code a set of
> struct file_operations. That way you could have "relayfs-like" files in
> any ram based file system that is being used. Then, a us
Zach Brown wrote:
> Only briefly. They've always seemed more involved than the sort of
> thing I was after. I'll try and sit down and investigate in more detail.
There's definitely an opportunity for interfacing here. If nothing else,
this clearly shows the interest for the kind of things both
OK, I finally come around to answering this ...
Roman Zippel wrote:
> Sorry, you missunderstood me. At the moment I'm only secondarily
> interested in the API details, primarily I want to work out the details of
> what exactly relayfs/ltt are supposed to do. One main question here I
> can't an
Hello Roman,
Roman Zippel wrote:
> Well, let's concentrate for a moment on the last thing and check later
> if and how they fit into relayfs. Since ltt will be first main user, let's
> optimize it for this.
> Also since relayfs is intended for large, fast data transfers, per cpu
> buffers are
Karim Yaghmour wrote:
> This is not good for any client that doesn't know beforehand the exact
> size of their data units, as in the case of LTT. If LTT has to use this
> code that means we are going to loose performance because we will need to
> fill an intermediate data str
Greg KH wrote:
> Are they willing to trade off the performance of LTT to get this? I
> thought this was being touted as a "when you need to test" type of
> thing, not a "run it all the time" type of feature.
The problem is that you never know beforehand when you're going to
get that weird glitch
Karim Yaghmour wrote:
> This is not good for any client that doesn't know beforehand the exact
> size of their data units, as in the case of LTT. If LTT has to use this
> code that means we are going to loose performance because we will need to
> fill an intermediate data str
Roman Zippel wrote:
> Ok, great.
> BTW I don't really expect the first version to be fully optimized (unless
> you want to :) ), but once the basics are right, that can still be added
> later.
Agreed. Tom will post updated patches sometime this week. I'll follow up
with the LTT stuff separately
- KRYPTIVA PACKAGED MESSAGE -
PACKAGING TYPE: SIGNED
Hello Mathieu,
Mathieu Desnoyers wrote:
> Yes, that was indeed the first way I implemented it, as a "disable" option. One of the
main thing we have to figure out before I modify this is if we want to have the generic version of
marke
- KRYPTIVA PACKAGED MESSAGE -
PACKAGING TYPE: SIGNED
Mathieu Desnoyers wrote:
> The problem with your proposal, I guess, is that people will have to add a
supplementary parameter to the macro.
>
> It is not uncommon to have two slightly versions of macros/functions in the
kernel (preemp
- KRYPTIVA PACKAGED MESSAGE -
PACKAGING TYPE: SIGNED
Mathieu Desnoyers wrote:
> The main goal of this config option is for embedded systems which doesn't support live
code modification. Maybe we can put that under "embedded sytems" menu ?
Not sure whether you had had other feedback on t
s thread have far more informed opinions about the
specifics than I could have. My priority was to clarify the basis for
the need being addressed.
Cheers,
--
Karim Yaghmour
CEO - Opersys inc. / www.opersys.com
http://twitter.com/karimyaghmour
Just wondering if anyone had some pointers on a comparison between the
various logging/buffering mechanisms out there (ring buffer, relay,
lttng buffering, etc.)? Googling was inconclusive.
Anything that has benchmarks/pros/cons would be great.
Thanks,
--
Karim Yaghmour
CEO - Opersys inc
mented by Google
itself to output trace info into trace_marker. And the systrace/atrace
tools made available to app developers need to get access to this
tracing info. So, if Android had tracing disabled, systrace/atrace
wouldn't work.
https://developer.android.com/tools/debugging/systrace.htm
from SoC vendors. So it's much likelier that an Androidized
kernel tree from Qualcomm or Intel is closer to what gets really shipped
than the two links above.
--
Karim Yaghmour
CEO - Opersys inc. / www.opersys.com
http://twitter.com/karimyaghmour
--
To unsubscribe from this list: send the line &
ter.js
> with a bunch of regex...
> including sched_switch: next_prio...
Yes, it does. This is why it's not meant for analyzing large traces.
--
Karim Yaghmour
CEO - Opersys inc. / www.opersys.com
http://twitter.com/karimyaghmour
--
To unsubscribe from this list: send the line "u
1 - 100 of 106 matches
Mail list logo
