From: Karim Yaghmour <karim@opersys.com> To: Linus Torvalds <torvalds@transmeta.com> Cc: John Levon <levon@movementarian.org>, Andrew Morton <akpm@zip.com.au>, Andrea Arcangeli <andrea@suse.de>, Rik van Riel <riel@conectiva.com.br>, "linux-mm@kvack.org" <linux-mm@kvack.org>, "Martin J. Bligh" <Martin.Bligh@us.ibm.com>, linux-kernel@vger.kernel.org, Richard Moore <richardj_moore@uk.ibm.com>, bob <bob@watson.ibm.com> Subject: Re: Enhanced profiling support (was Re: vm lock contention reduction) Date: Mon, 08 Jul 2002 14:41:00 -0400 [thread overview] Message-ID: <3D29DCBC.5ADB7BE8@opersys.com> (raw) In-Reply-To: Pine.LNX.4.44.0207081039390.2921-100000@home.transmeta.com Linus Torvalds wrote: > On Mon, 8 Jul 2002, John Levon wrote: > > How do you see such dentry names being exported to user-space for the > > profiling daemon to access ? The current oprofile scheme is, um, less > > than ideal ... > > Ok, I'll outline my personal favourite interface, but I'd also better > point out that while I've thought a bit about what I'd like to have and > how it could be implemented in the kernel, I have _not_ actually tried any > of it out, much less thought about what the user level stuff really needs. Sure. I've done some work on profiling using trace hooks. Hopefully the following is useful. > Anyway, here goes a straw-man: > > - I'd associate each profiling event with a dentry/offset pair, simply > because that's the highest-level thing that the kernel knows about and > that is "static". dentry + offset: on a 32bit machine, this is 8 bytes total per event being profiled. This is a lot of information if you are trying you have a high volume throughput. You can almost always skip the dentry since you know scheduling changes and since you can catch a system-state snapshot at the begining of the profiling. After that, the eip is sufficient and can easily be correlated to a meaningfull entry in a file in user-space. > - I'd suggest that the profiler explicitly mark the dentries it wants > profiled, so that the kernel can throw away events that we're not > interested in. The marking function would return a cookie to user > space, and increment the dentry count (along with setting the > "profile" flag in the dentry) Or the kernel can completely ignore this sort of selection and leave it all to the agent responsible for collecting the events. This is what is done in LTT. Currently, you can select one PID, GID, UID, but this is easily extendable to include many. Of course if you agree to having the task struct have "trace" or "profile" field, then this would be much easier. > - the "cookie" (which would most easily just be the kernel address of the > dentry) would be the thing that we give to user-space (along with > offset) on profile read. The user app can turn it back into a filename. That's the typical scheme and the one possible with the data retrieved by LTT. > Whether it is the original "mark this file for profiling" phase that saves > away the cookie<->filename association, or whether we also have a system > call for "return the path of this cookie", I don't much care about. > Details, details. > > Anyway, what would be the preferred interface from user level? The approach LTT takes is that no part in the kernel should actually care about the user level needs. Anything in user level that has to modify the tracing/profiling makes its requests to the trace driver, /dev/tracer. No additional system calls, no special cases in the main kernel code. Only 3 main files: kernel/trace.c: The main entry point for all events (trace_event()) drivers/trace/tracer.c: The trace driver include/linux/trace.h: The trace hook definitions Cheers, Karim =================================================== Karim Yaghmour karim@opersys.com Embedded and Real-Time Linux Expert ===================================================
WARNING: multiple messages have this Message-ID (diff)
From: Karim Yaghmour <karim@opersys.com> To: Linus Torvalds <torvalds@transmeta.com> Cc: John Levon <levon@movementarian.org>, Andrew Morton <akpm@zip.com.au>, Andrea Arcangeli <andrea@suse.de>, Rik van Riel <riel@conectiva.com.br>, "linux-mm@kvack.org" <linux-mm@kvack.org>, "Martin J. Bligh" <Martin.Bligh@us.ibm.com>, linux-kernel@vger.kernel.org, Richard Moore <richardj_moore@uk.ibm.com>, bob <bob@watson.ibm.com> Subject: Re: Enhanced profiling support (was Re: vm lock contention reduction) Date: Mon, 08 Jul 2002 14:41:00 -0400 [thread overview] Message-ID: <3D29DCBC.5ADB7BE8@opersys.com> (raw) In-Reply-To: Pine.LNX.4.44.0207081039390.2921-100000@home.transmeta.com Linus Torvalds wrote: > On Mon, 8 Jul 2002, John Levon wrote: > > How do you see such dentry names being exported to user-space for the > > profiling daemon to access ? The current oprofile scheme is, um, less > > than ideal ... > > Ok, I'll outline my personal favourite interface, but I'd also better > point out that while I've thought a bit about what I'd like to have and > how it could be implemented in the kernel, I have _not_ actually tried any > of it out, much less thought about what the user level stuff really needs. Sure. I've done some work on profiling using trace hooks. Hopefully the following is useful. > Anyway, here goes a straw-man: > > - I'd associate each profiling event with a dentry/offset pair, simply > because that's the highest-level thing that the kernel knows about and > that is "static". dentry + offset: on a 32bit machine, this is 8 bytes total per event being profiled. This is a lot of information if you are trying you have a high volume throughput. You can almost always skip the dentry since you know scheduling changes and since you can catch a system-state snapshot at the begining of the profiling. After that, the eip is sufficient and can easily be correlated to a meaningfull entry in a file in user-space. > - I'd suggest that the profiler explicitly mark the dentries it wants > profiled, so that the kernel can throw away events that we're not > interested in. The marking function would return a cookie to user > space, and increment the dentry count (along with setting the > "profile" flag in the dentry) Or the kernel can completely ignore this sort of selection and leave it all to the agent responsible for collecting the events. This is what is done in LTT. Currently, you can select one PID, GID, UID, but this is easily extendable to include many. Of course if you agree to having the task struct have "trace" or "profile" field, then this would be much easier. > - the "cookie" (which would most easily just be the kernel address of the > dentry) would be the thing that we give to user-space (along with > offset) on profile read. The user app can turn it back into a filename. That's the typical scheme and the one possible with the data retrieved by LTT. > Whether it is the original "mark this file for profiling" phase that saves > away the cookie<->filename association, or whether we also have a system > call for "return the path of this cookie", I don't much care about. > Details, details. > > Anyway, what would be the preferred interface from user level? The approach LTT takes is that no part in the kernel should actually care about the user level needs. Anything in user level that has to modify the tracing/profiling makes its requests to the trace driver, /dev/tracer. No additional system calls, no special cases in the main kernel code. Only 3 main files: kernel/trace.c: The main entry point for all events (trace_event()) drivers/trace/tracer.c: The trace driver include/linux/trace.h: The trace hook definitions Cheers, Karim =================================================== Karim Yaghmour karim@opersys.com Embedded and Real-Time Linux Expert =================================================== -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/
next prev parent reply other threads:[~2002-07-08 18:51 UTC|newest] Thread overview: 95+ messages / expand[flat|nested] mbox.gz Atom feed top 2002-07-04 23:05 vm lock contention reduction Andrew Morton 2002-07-04 23:26 ` Rik van Riel 2002-07-04 23:27 ` Rik van Riel 2002-07-05 1:37 ` Andrew Morton 2002-07-05 1:49 ` Rik van Riel 2002-07-05 2:18 ` Andrew Morton 2002-07-05 2:16 ` Rik van Riel 2002-07-05 2:53 ` Andrew Morton 2002-07-05 3:52 ` Benjamin LaHaise 2002-07-05 4:47 ` Linus Torvalds 2002-07-05 5:38 ` Andrew Morton 2002-07-05 5:51 ` Linus Torvalds 2002-07-05 6:08 ` Linus Torvalds 2002-07-05 6:27 ` Alexander Viro 2002-07-05 6:33 ` Andrew Morton 2002-07-05 7:33 ` Andrea Arcangeli 2002-07-07 2:50 ` Andrew Morton 2002-07-07 3:05 ` Linus Torvalds 2002-07-07 3:47 ` Andrew Morton 2002-07-08 11:39 ` Enhanced profiling support (was Re: vm lock contention reduction) John Levon 2002-07-08 11:39 ` John Levon 2002-07-08 17:52 ` Linus Torvalds 2002-07-08 17:52 ` Linus Torvalds 2002-07-08 18:41 ` Karim Yaghmour [this message] 2002-07-08 18:41 ` Karim Yaghmour 2002-07-10 2:22 ` John Levon 2002-07-10 2:22 ` John Levon 2002-07-10 4:16 ` Karim Yaghmour 2002-07-10 4:16 ` Karim Yaghmour 2002-07-10 4:38 ` John Levon 2002-07-10 4:38 ` John Levon 2002-07-10 5:46 ` Karim Yaghmour 2002-07-10 5:46 ` Karim Yaghmour 2002-07-10 13:10 ` bob 2002-07-10 13:10 ` bob 2002-07-09 16:57 ` John Levon 2002-07-09 19:56 ` Karim Yaghmour 2002-07-07 5:16 ` vm lock contention reduction Martin J. Bligh 2002-07-07 6:13 ` scalable kmap (was Re: vm lock contention reduction) Martin J. Bligh 2002-07-07 6:37 ` Andrew Morton 2002-07-07 7:53 ` Linus Torvalds 2002-07-07 9:04 ` Andrew Morton 2002-07-07 16:13 ` Martin J. Bligh 2002-07-07 18:31 ` Linus Torvalds 2002-07-07 18:55 ` Linus Torvalds 2002-07-07 19:02 ` Linus Torvalds 2002-07-08 7:24 ` Andrew Morton 2002-07-08 8:09 ` Andrea Arcangeli 2002-07-08 14:50 ` William Lee Irwin III 2002-07-08 20:39 ` Andrew Morton 2002-07-08 21:08 ` Benjamin LaHaise 2002-07-08 21:45 ` Andrew Morton 2002-07-08 22:24 ` Benjamin LaHaise 2002-07-07 16:00 ` Martin J. Bligh 2002-07-07 18:28 ` Linus Torvalds 2002-07-08 7:11 ` Andrea Arcangeli 2002-07-08 10:15 ` Eric W. Biederman 2002-07-08 7:00 ` Andrea Arcangeli 2002-07-08 17:29 ` Martin J. Bligh 2002-07-08 22:14 ` Linus Torvalds 2002-07-09 0:16 ` Andrew Morton 2002-07-09 3:17 ` Andrew Morton 2002-07-09 4:28 ` Martin J. Bligh 2002-07-09 5:28 ` Andrew Morton 2002-07-09 6:15 ` Martin J. Bligh 2002-07-09 6:30 ` William Lee Irwin III 2002-07-09 6:32 ` William Lee Irwin III 2002-07-09 16:08 ` Martin J. Bligh 2002-07-09 17:32 ` Andrea Arcangeli 2002-07-10 5:32 ` Andrew Morton 2002-07-10 22:43 ` Martin J. Bligh 2002-07-10 23:08 ` Andrew Morton 2002-07-10 23:26 ` Martin J. Bligh 2002-07-11 0:19 ` Andrew Morton 2002-07-12 17:48 ` Martin J. Bligh 2002-07-13 11:18 ` Andrea Arcangeli 2002-07-09 13:59 ` Benjamin LaHaise 2002-07-08 0:38 ` vm lock contention reduction William Lee Irwin III 2002-07-05 6:46 ` Andrew Morton 2002-07-05 14:25 ` Rik van Riel 2002-07-05 23:11 ` William Lee Irwin III 2002-07-05 23:48 ` Andrew Morton 2002-07-06 0:11 ` Rik van Riel 2002-07-06 0:31 ` Linus Torvalds 2002-07-06 0:45 ` Rik van Riel 2002-07-06 0:48 ` Andrew Morton 2002-07-08 0:59 ` William Lee Irwin III 2002-07-10 14:28 Enhanced profiling support (was Re: vm lock contention reduction) Richard J Moore 2002-07-10 14:28 ` Richard J Moore 2002-07-10 20:30 ` Karim Yaghmour 2002-07-10 20:30 ` Karim Yaghmour 2002-07-10 21:41 ` Andrea Arcangeli 2002-07-10 21:41 ` Andrea Arcangeli 2002-07-11 4:47 ` Karim Yaghmour 2002-07-11 4:59 ` Karim Yaghmour
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=3D29DCBC.5ADB7BE8@opersys.com \ --to=karim@opersys.com \ --cc=Martin.Bligh@us.ibm.com \ --cc=akpm@zip.com.au \ --cc=andrea@suse.de \ --cc=bob@watson.ibm.com \ --cc=levon@movementarian.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=richardj_moore@uk.ibm.com \ --cc=riel@conectiva.com.br \ --cc=torvalds@transmeta.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.