You're actually asking multiple questions here, because in order
to verify if a particular operating system zero-fills memory pages
when they are freed from an address space, you'd need to first know
which kernel function is called to zero-fill the pages, right?
I created a simple DTrace script to trace all kernel functions
executed when a process exits;
-------------------------------------- ex.d -------
#!/usr/sbin/dtrace -s
#pragma D option flowindent
proc::proc_exit:exit
/ pid == $target /
{
self->trace = 1;
}
fbt:::
/ self->trace /
{
}
------------------------------------------------------
This script uses the DTrace proc provider and enables the exit
probe, which fires when a process exits. The predicate following
the probe, / pid == $target /, tests that the PID is one I'm interested in.
In this case, I'm running this script as (the script name is ex.d);
#ex.d -c ./mem
The "-c" flag instructs DTrace to plug the PID of the command
into the $target macro. Very handy. The "mem" program is a
quick 10 line C program I wrote that malloc's 50MB of RAM,
touches every page, and exits.
So when the proc::proc_exit:exit probe fires, and
the predicate evaluates TRUE, meaning it's the PID
I'm interested in, we set a thread local variable called
"trace" to 1.
The second probe entry, fbt:::, basically enables every fbt
provider probe. The fbt provider allows us to instrument the
entry and return point for pretty much every kernel function.
With the trace flag set, and the flowindent option set in the script,
when the process exits, I get an easy-to-read list of kernel functions
called.
None of this answers the question "are memory pages zero filled
when they are freed", because I don't (or at least did not) know the
name of the kernel function the zero-fills memory pages.
When I went through the kernel calls, nothing really jumped out at
me as a zero-fill function. It was clear I was freeing memory -
I saw as_free() (free an address space) which loops through the
segments in the address space, calling the segment-specific
unmap code, and eventually page_free(). But nothing that looked
like it was zero'ing out freed pages. So...
I know for sure that allocation of anonymous memory uses a ZFOD
(zero fill on demand) mechanism, so I decided to have a look at that.
DTrace makes this so easy - I have three probes called "zfod" available,
that each reside in a different kernel function - anon_map_createpages(),
anon_zero() and anon_map_getpages(). So I did some dtrace'ing on these
functions to see what they called, and discovered pagezero(), which sounded
a lot to me like a "zero fill a memory page" function. A quick look at
the source code verified this. So....
I know empirically that memory pages are zero-filled when allocated
(anon memory pages that is);
# dtrace -n 'fbt::pagezero:entry / pid == $target / { @c = count(); }'
-c ./mem
dtrace: description 'fbt::pagezero:entry ' matched 1 probe
dtrace: pid 5016 has exited
6642
In the dtrace above, I enabled the entry point to the kernel
pagezero() function, and used the DTrace count() aggregating
function to count the number of times I call it. I know my
mem program allocates 50MB, which is 6400 8k memory pages.
I see I called pagezero() 6642 times, which aligns pretty well with
what I expected (other anon allocations happen when you start
a process beyond my 50MB heap segment).
As for process exit and freed pages, I have not found any
indication that freed pages are zero'd. Mind you, this does not
represent an exhaustive study (I only spent a few minutes on it).
HTH,
/jim
Dmitry Afanasyev wrote:
Hello.
I've got a scrip for systemtap and Linux kernel, that check if physical memory
is filled by zero after process dies. The scrip is attached.
The probe is set in the free_pages_bulk function, which frees number of memory
pages using _free_one_page. I can't set probe in _free_one_page, because it is
inline and systemtap doesn't support it. The result is the address of first
dirty(not filled by zero) page in the bulk.
I need the same script for Solaris kernel. I guess that DTrace provides the
same functionality as systemtap, but I do not familiar with Solaris kernel at
all.
------------------------------------------------------------------------
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
