Hi -
On Mon, Apr 16, 2007 at 11:36:05PM +0200, Andi Kleen wrote:
> Christoph Hellwig <[EMAIL PROTECTED]> writes:
> > and [systemtap] does a lot of really wrong things in it's
> > runtime). [...]
(Thanks, Christoph, for at least a few specifics. Some of them have
already been dealt with in the
Christoph Hellwig <[EMAIL PROTECTED]> writes:
> and does a lot of really wrong things in it's runtime).
I must agree with that. Perhaps it would be good if its runtime code
was posted to l-k at some point and reviewed in the standard way
even when it isn't merged.
-Andi
-
To unsubscribe from
On Fri, Apr 13, 2007 at 10:08:27AM -0400, Theodore Tso wrote:
> On Fri, Apr 13, 2007 at 01:40:08PM +1000, Nick Piggin wrote:
> > With systemtap scripts, you could walk pagetables and print *the exact
> > page information you want*, or you could walk pfns, or LRU, or page_tree,
> > or walk the page
On Fri, Apr 13, 2007 at 05:17:00PM -0400, Frank Ch. Eigler wrote:
> It may be worthwhile to remind people that it is easy to use systemtap
> only to the extent of automating the placement of kprobes: just to
> perform the function-name/source-file/line-number triplet to PC
> mapping. They can use
On Fri, Apr 13, 2007 at 05:17:00PM -0400, Frank Ch. Eigler wrote:
It may be worthwhile to remind people that it is easy to use systemtap
only to the extent of automating the placement of kprobes: just to
perform the function-name/source-file/line-number triplet to PC
mapping. They can use
On Fri, Apr 13, 2007 at 10:08:27AM -0400, Theodore Tso wrote:
On Fri, Apr 13, 2007 at 01:40:08PM +1000, Nick Piggin wrote:
With systemtap scripts, you could walk pagetables and print *the exact
page information you want*, or you could walk pfns, or LRU, or page_tree,
or walk the page tree
Christoph Hellwig [EMAIL PROTECTED] writes:
and does a lot of really wrong things in it's runtime).
I must agree with that. Perhaps it would be good if its runtime code
was posted to l-k at some point and reviewed in the standard way
even when it isn't merged.
-Andi
-
To unsubscribe from this
Hi -
On Mon, Apr 16, 2007 at 11:36:05PM +0200, Andi Kleen wrote:
Christoph Hellwig [EMAIL PROTECTED] writes:
and [systemtap] does a lot of really wrong things in it's
runtime). [...]
(Thanks, Christoph, for at least a few specifics. Some of them have
already been dealt with in the recent
On Thu, Apr 12, 2007 at 09:23:45PM -0500, Matt Mackall wrote:
> On Fri, Apr 13, 2007 at 12:21:25PM +1000, Nick Piggin wrote:
> > Matt Mackall wrote:
> > >On Fri, Apr 13, 2007 at 11:42:29AM +1000, Nick Piggin wrote:
> >
> > >>If kprobes is simply crappy and doesn't work properly for this, then I
>
On Thu, Apr 12, 2007 at 09:23:45PM -0500, Matt Mackall wrote:
On Fri, Apr 13, 2007 at 12:21:25PM +1000, Nick Piggin wrote:
Matt Mackall wrote:
On Fri, Apr 13, 2007 at 11:42:29AM +1000, Nick Piggin wrote:
If kprobes is simply crappy and doesn't work properly for this, then I
could
Christoph Hellwig <[EMAIL PROTECTED]> writes:
> [...]
> > merge it in the first place?
>
> It's very nice to poke deep into the kernel for development purposes.
> For example for the spu scheduler work I'm doing currently I have
> a module using kprobes (note the systemtap crap because it's
On Fri, 13 Apr 2007 12:24:51 -0500 Matt Mackall <[EMAIL PROTECTED]> wrote:
> > > From /proc/kpagemap + /proc/*/pagemap, you can
> > > basically synthesize any statistic you want, including all the
> > > existing ones. For some data, /proc/pid/smaps (or /proc/meminfo) will
> > > be considerably
On Fri, Apr 13, 2007 at 10:03:56AM -0700, Andrew Morton wrote:
> On Fri, 13 Apr 2007 11:24:36 -0500 Matt Mackall <[EMAIL PROTECTED]> wrote:
>
> > > It *will* be viable. If the application wants to know if a page is dirty,
> > > it looks up "PG_dirty" in /proc/pg_foo-to-bitnumber and uses
On Fri, Apr 13, 2007 at 12:18:56PM +1000, Nick Piggin wrote:
> Can't you just traverse arbitrary kernel data structures at a given point
> in time, exactly like the /proc/ call is doing?
Perhaps.
My understanding is that you hook a kprobe to an event. An event is a
particular instruction getting
On Fri, 13 Apr 2007 11:24:36 -0500 Matt Mackall <[EMAIL PROTECTED]> wrote:
> > It *will* be viable. If the application wants to know if a page is dirty,
> > it looks up "PG_dirty" in /proc/pg_foo-to-bitnumber and uses PG_dirty's
> > numerical offset when inspecting fields in /proc/kpagemap. If
On Thu, Apr 12, 2007 at 05:42:01PM -0700, Andrew Morton wrote:
> On Fri, 13 Apr 2007 10:15:24 +1000 Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> > >>+ ((char *)page)[1] = PAGE_SHIFT;
> > >
> > >
> > > OK.
> >
> > Shouldn't we just expose page size and endianness by other
On Fri, Apr 13, 2007 at 01:40:08PM +1000, Nick Piggin wrote:
> With systemtap scripts, you could walk pagetables and print *the exact
> page information you want*, or you could walk pfns, or LRU, or page_tree,
> or walk the page tree then the rmap structures. And you can selectively
> cull out
Ananth N Mavinakayanahalli wrote:
On Fri, Apr 13, 2007 at 12:50:20PM +1000, Nick Piggin wrote:
It definitely seems like you can use some kernel functions, but the
ones I saw may just be systemtap facilities. But what is so surprising
about being able to call a kernel function when running in
On Fri, Apr 13, 2007 at 12:54:36PM +1000, Nick Piggin wrote:
> Matt Mackall wrote:
> >On Fri, Apr 13, 2007 at 12:21:25PM +1000, Nick Piggin wrote:
> >
> >>Matt Mackall wrote:
> >>
> >>>On Fri, Apr 13, 2007 at 11:42:29AM +1000, Nick Piggin wrote:
> >>
> If kprobes is simply crappy and doesn't
On Fri, Apr 13, 2007 at 12:50:20PM +1000, Nick Piggin wrote:
> Andrew Morton wrote:
> >On Fri, 13 Apr 2007 12:18:56 +1000 Nick Piggin <[EMAIL PROTECTED]>
> >wrote:
> >
> >
> >>>I guess one could generate an answer to the static question with
> >>>systemtap,
> >>>by accumulating running counts
On Fri, Apr 13, 2007 at 06:25:46PM +1000, Nick Piggin wrote:
> But at least make it into its own module with a debugfs interface or
> something. I mean, exposing a PG_name-to-nr and page count pfn and flags
> as a supposedly formal proc interface doesn't sound nice to me. Page
> flags does not
Christoph Hellwig wrote:
On Fri, Apr 13, 2007 at 06:03:45PM +1000, Nick Piggin wrote:
Yeah good point ;) I just meant the wider "we".
With all the problems kprobes has, something like poking deep into
kernel internals seems like a good thing to use it for instead of
hardcoding that stuff into
On Fri, Apr 13, 2007 at 08:51:42AM +0100, Christoph Hellwig wrote:
> Umm, folks. systemtap basically means people compile kernel modules
> from an odd scripting language with embedded C snipplets into kernel
> modules. The kernel modules don't use normal exported APIs but use
> kallsysms and
On Fri, Apr 13, 2007 at 06:03:45PM +1000, Nick Piggin wrote:
> Yeah good point ;) I just meant the wider "we".
>
> With all the problems kprobes has, something like poking deep into
> kernel internals seems like a good thing to use it for instead of
> hardcoding that stuff into the kernel. If
Christoph Hellwig wrote:
On Fri, Apr 13, 2007 at 05:05:47PM +1000, Nick Piggin wrote:
Ah, OK. Anyway, with kprobes/systemtap they can do whatever they like
and none of us need to care in the slightest ;)
Umm, folks. systemtap basically means people compile kernel modules
from an odd
On Fri, Apr 13, 2007 at 05:05:47PM +1000, Nick Piggin wrote:
> Ah, OK. Anyway, with kprobes/systemtap they can do whatever they like
> and none of us need to care in the slightest ;)
Umm, folks. systemtap basically means people compile kernel modules
from an odd scripting language with embedded
William Lee Irwin III wrote:
>> The EM guys are unwilling or unable for support-oriented reasons to
>> deal with anything but unmodified kernels as shipped by distros.
On Fri, Apr 13, 2007 at 05:03:43PM +1000, Nick Piggin wrote:
> And I think major distros ship with kprobes enabled, so that is
William Lee Irwin III wrote:
Andrew Morton wrote:
Then you just end up with the same thing, don't you?
On Fri, Apr 13, 2007 at 12:50:20PM +1000, Nick Piggin wrote:
Well _you_ do, because that happens to be exactly what you want. Bill
ends up with something that displays page_mapcount
William Lee Irwin III wrote:
Andrew Morton wrote:
Do a full pagetable walk, with all the associated locking from within
a systemtap script? I'd be surprised. Maybe if it's mostly hand-coded
in C, perhaps. Then you just end up with the same thing, don't you?
On Fri, Apr 13, 2007 at
Andrew Morton wrote:
>> Do a full pagetable walk, with all the associated locking from within
>> a systemtap script? I'd be surprised. Maybe if it's mostly hand-coded
>> in C, perhaps. Then you just end up with the same thing, don't you?
On Fri, Apr 13, 2007 at 01:40:08PM +1000, Nick Piggin
Andrew Morton wrote:
>> Then you just end up with the same thing, don't you?
On Fri, Apr 13, 2007 at 12:50:20PM +1000, Nick Piggin wrote:
> Well _you_ do, because that happens to be exactly what you want. Bill
> ends up with something that displays page_mapcount instead. And I
> end up with
Andrew Morton wrote:
Then you just end up with the same thing, don't you?
On Fri, Apr 13, 2007 at 12:50:20PM +1000, Nick Piggin wrote:
Well _you_ do, because that happens to be exactly what you want. Bill
ends up with something that displays page_mapcount instead. And I
end up with something
Andrew Morton wrote:
Do a full pagetable walk, with all the associated locking from within
a systemtap script? I'd be surprised. Maybe if it's mostly hand-coded
in C, perhaps. Then you just end up with the same thing, don't you?
On Fri, Apr 13, 2007 at 01:40:08PM +1000, Nick Piggin wrote:
William Lee Irwin III wrote:
Andrew Morton wrote:
Do a full pagetable walk, with all the associated locking from within
a systemtap script? I'd be surprised. Maybe if it's mostly hand-coded
in C, perhaps. Then you just end up with the same thing, don't you?
On Fri, Apr 13, 2007 at
William Lee Irwin III wrote:
Andrew Morton wrote:
Then you just end up with the same thing, don't you?
On Fri, Apr 13, 2007 at 12:50:20PM +1000, Nick Piggin wrote:
Well _you_ do, because that happens to be exactly what you want. Bill
ends up with something that displays page_mapcount
William Lee Irwin III wrote:
The EM guys are unwilling or unable for support-oriented reasons to
deal with anything but unmodified kernels as shipped by distros.
On Fri, Apr 13, 2007 at 05:03:43PM +1000, Nick Piggin wrote:
And I think major distros ship with kprobes enabled, so that is yet
On Fri, Apr 13, 2007 at 05:05:47PM +1000, Nick Piggin wrote:
Ah, OK. Anyway, with kprobes/systemtap they can do whatever they like
and none of us need to care in the slightest ;)
Umm, folks. systemtap basically means people compile kernel modules
from an odd scripting language with embedded C
Christoph Hellwig wrote:
On Fri, Apr 13, 2007 at 05:05:47PM +1000, Nick Piggin wrote:
Ah, OK. Anyway, with kprobes/systemtap they can do whatever they like
and none of us need to care in the slightest ;)
Umm, folks. systemtap basically means people compile kernel modules
from an odd
On Fri, Apr 13, 2007 at 06:03:45PM +1000, Nick Piggin wrote:
Yeah good point ;) I just meant the wider we.
With all the problems kprobes has, something like poking deep into
kernel internals seems like a good thing to use it for instead of
hardcoding that stuff into the kernel. If not, then
On Fri, Apr 13, 2007 at 08:51:42AM +0100, Christoph Hellwig wrote:
Umm, folks. systemtap basically means people compile kernel modules
from an odd scripting language with embedded C snipplets into kernel
modules. The kernel modules don't use normal exported APIs but use
kallsysms and dwarf
Christoph Hellwig wrote:
On Fri, Apr 13, 2007 at 06:03:45PM +1000, Nick Piggin wrote:
Yeah good point ;) I just meant the wider we.
With all the problems kprobes has, something like poking deep into
kernel internals seems like a good thing to use it for instead of
hardcoding that stuff into
On Fri, Apr 13, 2007 at 06:25:46PM +1000, Nick Piggin wrote:
But at least make it into its own module with a debugfs interface or
something. I mean, exposing a PG_name-to-nr and page count pfn and flags
as a supposedly formal proc interface doesn't sound nice to me. Page
flags does not tell
On Fri, Apr 13, 2007 at 12:50:20PM +1000, Nick Piggin wrote:
Andrew Morton wrote:
On Fri, 13 Apr 2007 12:18:56 +1000 Nick Piggin [EMAIL PROTECTED]
wrote:
I guess one could generate an answer to the static question with
systemtap,
by accumulating running counts across the application
On Fri, Apr 13, 2007 at 12:54:36PM +1000, Nick Piggin wrote:
Matt Mackall wrote:
On Fri, Apr 13, 2007 at 12:21:25PM +1000, Nick Piggin wrote:
Matt Mackall wrote:
On Fri, Apr 13, 2007 at 11:42:29AM +1000, Nick Piggin wrote:
If kprobes is simply crappy and doesn't work properly for this,
Ananth N Mavinakayanahalli wrote:
On Fri, Apr 13, 2007 at 12:50:20PM +1000, Nick Piggin wrote:
It definitely seems like you can use some kernel functions, but the
ones I saw may just be systemtap facilities. But what is so surprising
about being able to call a kernel function when running in
On Fri, Apr 13, 2007 at 01:40:08PM +1000, Nick Piggin wrote:
With systemtap scripts, you could walk pagetables and print *the exact
page information you want*, or you could walk pfns, or LRU, or page_tree,
or walk the page tree then the rmap structures. And you can selectively
cull out items
On Thu, Apr 12, 2007 at 05:42:01PM -0700, Andrew Morton wrote:
On Fri, 13 Apr 2007 10:15:24 +1000 Nick Piggin [EMAIL PROTECTED] wrote:
+ ((char *)page)[1] = PAGE_SHIFT;
OK.
Shouldn't we just expose page size and endianness by other means? (another
file
On Fri, 13 Apr 2007 11:24:36 -0500 Matt Mackall [EMAIL PROTECTED] wrote:
It *will* be viable. If the application wants to know if a page is dirty,
it looks up PG_dirty in /proc/pg_foo-to-bitnumber and uses PG_dirty's
numerical offset when inspecting fields in /proc/kpagemap. If correctly
On Fri, Apr 13, 2007 at 12:18:56PM +1000, Nick Piggin wrote:
Can't you just traverse arbitrary kernel data structures at a given point
in time, exactly like the /proc/ call is doing?
Perhaps.
My understanding is that you hook a kprobe to an event. An event is a
particular instruction getting
On Fri, Apr 13, 2007 at 10:03:56AM -0700, Andrew Morton wrote:
On Fri, 13 Apr 2007 11:24:36 -0500 Matt Mackall [EMAIL PROTECTED] wrote:
It *will* be viable. If the application wants to know if a page is dirty,
it looks up PG_dirty in /proc/pg_foo-to-bitnumber and uses PG_dirty's
On Fri, 13 Apr 2007 12:24:51 -0500 Matt Mackall [EMAIL PROTECTED] wrote:
From /proc/kpagemap + /proc/*/pagemap, you can
basically synthesize any statistic you want, including all the
existing ones. For some data, /proc/pid/smaps (or /proc/meminfo) will
be considerably more efficient.
Christoph Hellwig [EMAIL PROTECTED] writes:
[...]
merge it in the first place?
It's very nice to poke deep into the kernel for development purposes.
For example for the spu scheduler work I'm doing currently I have
a module using kprobes (note the systemtap crap because it's big,
Andrew Morton wrote:
On Fri, 13 Apr 2007 12:18:56 +1000 Nick Piggin <[EMAIL PROTECTED]> wrote:
I guess one could generate an answer to the static question with systemtap,
by accumulating running counts across the application lifetime and then
snapshotting them. Sounds hard though.
Can't
Nick Piggin wrote:
Andrew Morton wrote:
Then you just end up with the same thing, don't you?
Well _you_ do, because that happens to be exactly what you want. Bill
ends up with something that displays page_mapcount instead. And I
end up with something that traverses LRU lists rather than
Matt Mackall wrote:
On Fri, Apr 13, 2007 at 12:21:25PM +1000, Nick Piggin wrote:
Matt Mackall wrote:
On Fri, Apr 13, 2007 at 11:42:29AM +1000, Nick Piggin wrote:
If kprobes is simply crappy and doesn't work properly for this, then I
could accept that. I'm not someone trying to get this
Andrew Morton wrote:
On Fri, 13 Apr 2007 12:18:56 +1000 Nick Piggin <[EMAIL PROTECTED]> wrote:
I guess one could generate an answer to the static question with systemtap,
by accumulating running counts across the application lifetime and then
snapshotting them. Sounds hard though.
Can't
On Fri, Apr 13, 2007 at 12:21:25PM +1000, Nick Piggin wrote:
> Matt Mackall wrote:
> >On Fri, Apr 13, 2007 at 11:42:29AM +1000, Nick Piggin wrote:
>
> >>If kprobes is simply crappy and doesn't work properly for this, then I
> >>could accept that. I'm not someone trying to get this info. So why
On Fri, 13 Apr 2007 12:18:56 +1000 Nick Piggin <[EMAIL PROTECTED]> wrote:
> > I guess one could generate an answer to the static question with systemtap,
> > by accumulating running counts across the application lifetime and then
> > snapshotting them. Sounds hard though.
>
> Can't you just
Matt Mackall wrote:
On Thu, Apr 12, 2007 at 06:57:23PM -0700, Andrew Morton wrote:
I guess one could generate an answer to the static question with systemtap,
by accumulating running counts across the application lifetime and then
snapshotting them. Sounds hard though.
You'd have to do it
Matt Mackall wrote:
On Fri, Apr 13, 2007 at 11:42:29AM +1000, Nick Piggin wrote:
If kprobes is simply crappy and doesn't work properly for this, then I
could accept that. I'm not someone trying to get this info. So why can't
it be used? (not just for kpagemap, but for clear_refs and all that
Andrew Morton wrote:
On Fri, 13 Apr 2007 11:42:29 +1000 Nick Piggin <[EMAIL PROTECTED]> wrote:
Maybe. How about LRU? Reclaim performance is bad, and you want to work out
which pages keep going off the end of it, or which pages keep getting
written out via it, or who's pages are on the active
On Thu, Apr 12, 2007 at 06:57:23PM -0700, Andrew Morton wrote:
> I guess one could generate an answer to the static question with systemtap,
> by accumulating running counts across the application lifetime and then
> snapshotting them. Sounds hard though.
You'd have to do it from boot onward to
Matt Mackall wrote:
On Fri, Apr 13, 2007 at 11:01:41AM +1000, Nick Piggin wrote:
Basically: to show what the hell's going on in the VM.
kprobes / systemtap isn't good enough?
It's not really a good match to the kprobes model. I'm not interested
in events, per se. I don't want to need to
On Fri, Apr 13, 2007 at 11:42:29AM +1000, Nick Piggin wrote:
> >Instead, one says "what pages are being used by my application", then, for
>
> That includes unmapped pagecache being used by my application, doesn't it?
> Maybe that's too hard to do via /proc so we forget about it...
It'd be
On Fri, 13 Apr 2007 11:42:29 +1000 Nick Piggin <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> > On Fri, 13 Apr 2007 11:14:20 +1000 Nick Piggin <[EMAIL PROTECTED]> wrote:
> >
> >
> >>Andrew Morton wrote:
>
> >>>It *will* be viable. If the application wants to know if a page is dirty,
>
On Fri, Apr 13, 2007 at 11:01:41AM +1000, Nick Piggin wrote:
> >Basically: to show what the hell's going on in the VM.
>
> kprobes / systemtap isn't good enough?
It's not really a good match to the kprobes model. I'm not interested
in events, per se. I don't want to need to know about every
Andrew Morton wrote:
On Fri, 13 Apr 2007 11:14:20 +1000 Nick Piggin <[EMAIL PROTECTED]> wrote:
Andrew Morton wrote:
It *will* be viable. If the application wants to know if a page is dirty,
it looks up "PG_dirty" in /proc/pg_foo-to-bitnumber and uses PG_dirty's
numerical offset when
On Fri, 13 Apr 2007 11:14:20 +1000 Nick Piggin <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> > On Fri, 13 Apr 2007 10:15:24 +1000 Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> + for (; i < 2 * chunk / KPMSIZE; i += 2, pfn++) {
> + ppage =
Andrew Morton wrote:
On Fri, 13 Apr 2007 10:15:24 +1000 Nick Piggin <[EMAIL PROTECTED]> wrote:
+ for (; i < 2 * chunk / KPMSIZE; i += 2, pfn++) {
+ ppage = pfn_to_page(pfn);
+ if (!ppage) {
+ page[i] = 0;
Matt Mackall wrote:
On Fri, Apr 13, 2007 at 10:15:24AM +1000, Nick Piggin wrote:
Andrew Morton wrote:
On Thu, 12 Apr 2007 16:10:50 -0700
William Lee Irwin III <[EMAIL PROTECTED]> wrote:
+ while (count > 0) {
+ chunk = min_t(size_t, count, PAGE_SIZE);
+ i
On Fri, 13 Apr 2007 10:15:24 +1000 Nick Piggin <[EMAIL PROTECTED]> wrote:
> >>+ ((char *)page)[1] = PAGE_SHIFT;
> >
> >
> > OK.
>
> Shouldn't we just expose page size and endianness by other means? (another
> file or
> syscall).
I don't think so - this file exposes
On Fri, Apr 13, 2007 at 10:15:24AM +1000, Nick Piggin wrote:
> Andrew Morton wrote:
> >On Thu, 12 Apr 2007 16:10:50 -0700
> >William Lee Irwin III <[EMAIL PROTECTED]> wrote:
>
> >>+ while (count > 0) {
> >>+ chunk = min_t(size_t, count, PAGE_SIZE);
> >>+ i = 0;
>
On Thu, Apr 12, 2007 at 04:32:35PM -0700, Andrew Morton wrote:
> On Thu, 12 Apr 2007 16:10:50 -0700
> William Lee Irwin III <[EMAIL PROTECTED]> wrote:
>
> > On Tue, Apr 03, 2007 at 09:43:30PM -0500, Matt Mackall wrote:
> > > This patch series introduces /proc/pid/pagemap and /proc/kpagemap,
> > >
William Lee Irwin III wrote:
On Thu, 12 Apr 2007 16:10:50 -0700 William Lee Irwin III <[EMAIL PROTECTED]>
wrote:
This solves a real-life problem for Oracle system monitoring software
(specifically EM). Among the tasks it must carry out is determining
per-process memory footprint of a set of
Andrew Morton wrote:
On Thu, 12 Apr 2007 16:10:50 -0700
William Lee Irwin III <[EMAIL PROTECTED]> wrote:
+ while (count > 0) {
+ chunk = min_t(size_t, count, PAGE_SIZE);
+ i = 0;
+
+ if (pfn == -1) {
+ page[0] = 0;
+
On Thu, 12 Apr 2007 16:10:50 -0700 William Lee Irwin III <[EMAIL PROTECTED]>
wrote:
>> This solves a real-life problem for Oracle system monitoring software
>> (specifically EM). Among the tasks it must carry out is determining
>> per-process memory footprint of a set of cooperating tasks (i.e.
On Thu, 12 Apr 2007 16:10:50 -0700
William Lee Irwin III <[EMAIL PROTECTED]> wrote:
> On Tue, Apr 03, 2007 at 09:43:30PM -0500, Matt Mackall wrote:
> > This patch series introduces /proc/pid/pagemap and /proc/kpagemap,
> > which allow detailed run-time examination of process memory usage at a
> >
On Tue, Apr 03, 2007 at 09:43:30PM -0500, Matt Mackall wrote:
> This patch series introduces /proc/pid/pagemap and /proc/kpagemap,
> which allow detailed run-time examination of process memory usage at a
> page granularity.
> The first several patches whip the page-walking code introduced for
>
On Tue, Apr 03, 2007 at 09:43:30PM -0500, Matt Mackall wrote:
This patch series introduces /proc/pid/pagemap and /proc/kpagemap,
which allow detailed run-time examination of process memory usage at a
page granularity.
The first several patches whip the page-walking code introduced for
On Thu, 12 Apr 2007 16:10:50 -0700
William Lee Irwin III [EMAIL PROTECTED] wrote:
On Tue, Apr 03, 2007 at 09:43:30PM -0500, Matt Mackall wrote:
This patch series introduces /proc/pid/pagemap and /proc/kpagemap,
which allow detailed run-time examination of process memory usage at a
page
On Thu, 12 Apr 2007 16:10:50 -0700 William Lee Irwin III [EMAIL PROTECTED]
wrote:
This solves a real-life problem for Oracle system monitoring software
(specifically EM). Among the tasks it must carry out is determining
per-process memory footprint of a set of cooperating tasks (i.e. Oracle
Andrew Morton wrote:
On Thu, 12 Apr 2007 16:10:50 -0700
William Lee Irwin III [EMAIL PROTECTED] wrote:
+ while (count 0) {
+ chunk = min_t(size_t, count, PAGE_SIZE);
+ i = 0;
+
+ if (pfn == -1) {
+ page[0] = 0;
+
William Lee Irwin III wrote:
On Thu, 12 Apr 2007 16:10:50 -0700 William Lee Irwin III [EMAIL PROTECTED]
wrote:
This solves a real-life problem for Oracle system monitoring software
(specifically EM). Among the tasks it must carry out is determining
per-process memory footprint of a set of
On Thu, Apr 12, 2007 at 04:32:35PM -0700, Andrew Morton wrote:
On Thu, 12 Apr 2007 16:10:50 -0700
William Lee Irwin III [EMAIL PROTECTED] wrote:
On Tue, Apr 03, 2007 at 09:43:30PM -0500, Matt Mackall wrote:
This patch series introduces /proc/pid/pagemap and /proc/kpagemap,
which allow
On Fri, Apr 13, 2007 at 10:15:24AM +1000, Nick Piggin wrote:
Andrew Morton wrote:
On Thu, 12 Apr 2007 16:10:50 -0700
William Lee Irwin III [EMAIL PROTECTED] wrote:
+ while (count 0) {
+ chunk = min_t(size_t, count, PAGE_SIZE);
+ i = 0;
+
+
On Fri, 13 Apr 2007 10:15:24 +1000 Nick Piggin [EMAIL PROTECTED] wrote:
+ ((char *)page)[1] = PAGE_SHIFT;
OK.
Shouldn't we just expose page size and endianness by other means? (another
file or
syscall).
I don't think so - this file exposes fairly deep kernel
Matt Mackall wrote:
On Fri, Apr 13, 2007 at 10:15:24AM +1000, Nick Piggin wrote:
Andrew Morton wrote:
On Thu, 12 Apr 2007 16:10:50 -0700
William Lee Irwin III [EMAIL PROTECTED] wrote:
+ while (count 0) {
+ chunk = min_t(size_t, count, PAGE_SIZE);
+ i =
Andrew Morton wrote:
On Fri, 13 Apr 2007 10:15:24 +1000 Nick Piggin [EMAIL PROTECTED] wrote:
+ for (; i 2 * chunk / KPMSIZE; i += 2, pfn++) {
+ ppage = pfn_to_page(pfn);
+ if (!ppage) {
+ page[i] = 0;
+
On Fri, 13 Apr 2007 11:14:20 +1000 Nick Piggin [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
On Fri, 13 Apr 2007 10:15:24 +1000 Nick Piggin [EMAIL PROTECTED] wrote:
+ for (; i 2 * chunk / KPMSIZE; i += 2, pfn++) {
+ ppage = pfn_to_page(pfn);
+
Andrew Morton wrote:
On Fri, 13 Apr 2007 11:14:20 +1000 Nick Piggin [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
It *will* be viable. If the application wants to know if a page is dirty,
it looks up PG_dirty in /proc/pg_foo-to-bitnumber and uses PG_dirty's
numerical offset when
On Fri, Apr 13, 2007 at 11:01:41AM +1000, Nick Piggin wrote:
Basically: to show what the hell's going on in the VM.
kprobes / systemtap isn't good enough?
It's not really a good match to the kprobes model. I'm not interested
in events, per se. I don't want to need to know about every single
On Fri, 13 Apr 2007 11:42:29 +1000 Nick Piggin [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
On Fri, 13 Apr 2007 11:14:20 +1000 Nick Piggin [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
It *will* be viable. If the application wants to know if a page is dirty,
it looks up PG_dirty
On Fri, Apr 13, 2007 at 11:42:29AM +1000, Nick Piggin wrote:
Instead, one says what pages are being used by my application, then, for
That includes unmapped pagecache being used by my application, doesn't it?
Maybe that's too hard to do via /proc so we forget about it...
It'd be really nice
Matt Mackall wrote:
On Fri, Apr 13, 2007 at 11:01:41AM +1000, Nick Piggin wrote:
Basically: to show what the hell's going on in the VM.
kprobes / systemtap isn't good enough?
It's not really a good match to the kprobes model. I'm not interested
in events, per se. I don't want to need to
On Thu, Apr 12, 2007 at 06:57:23PM -0700, Andrew Morton wrote:
I guess one could generate an answer to the static question with systemtap,
by accumulating running counts across the application lifetime and then
snapshotting them. Sounds hard though.
You'd have to do it from boot onward to get
Andrew Morton wrote:
On Fri, 13 Apr 2007 11:42:29 +1000 Nick Piggin [EMAIL PROTECTED] wrote:
Maybe. How about LRU? Reclaim performance is bad, and you want to work out
which pages keep going off the end of it, or which pages keep getting
written out via it, or who's pages are on the active
Matt Mackall wrote:
On Fri, Apr 13, 2007 at 11:42:29AM +1000, Nick Piggin wrote:
If kprobes is simply crappy and doesn't work properly for this, then I
could accept that. I'm not someone trying to get this info. So why can't
it be used? (not just for kpagemap, but for clear_refs and all that
Matt Mackall wrote:
On Thu, Apr 12, 2007 at 06:57:23PM -0700, Andrew Morton wrote:
I guess one could generate an answer to the static question with systemtap,
by accumulating running counts across the application lifetime and then
snapshotting them. Sounds hard though.
You'd have to do it
On Fri, 13 Apr 2007 12:18:56 +1000 Nick Piggin [EMAIL PROTECTED] wrote:
I guess one could generate an answer to the static question with systemtap,
by accumulating running counts across the application lifetime and then
snapshotting them. Sounds hard though.
Can't you just traverse
On Fri, Apr 13, 2007 at 12:21:25PM +1000, Nick Piggin wrote:
Matt Mackall wrote:
On Fri, Apr 13, 2007 at 11:42:29AM +1000, Nick Piggin wrote:
If kprobes is simply crappy and doesn't work properly for this, then I
could accept that. I'm not someone trying to get this info. So why can't
it be
1 - 100 of 106 matches
Mail list logo
