>>The page fault handler. When you write to a copy on write page its
actually
>>marked read-only in the hardware. The kernel copies the page marks
both
>>copies writable and fixes up the fault so that user space doesn't see
anything
>>happen.
Thank you very much for this clarification.
As said in my previous email, I am interested in adding a page coloring
fonctionnality into the linux kernel.
To do that I just have a get_free_page_by_address routine that is able
to do the same job as get_free_page (except that it takes care about the
physical adress of the page returned)
then I changed:
All calls to get_free_page in mm/filemap.c have been replaced by
get_free_page_by_address
In mm/memory.c:
the do_anonymous_page contains a get_free_page replaced by a
get_free_page_by_address
the do_wp_page contains a get_free_page replaced by a
get_free_page_by_address
This patch is giving very good results on simple fortran processes but
it
still looks like my patch is bypassed when doing forks.
I have done a grep get_free_page() into the whole linux kernel code and
I have many
get_free_page unmodified in the drivers section and in the fs directory
but I think
my user space pure computationnal application do not need that to be
coloured.
When I am using the following code:
===================================
char *a;
int i,n=0;
while(1)
{
a=malloc(sizeof(char)*8192) /* allocate 10 8k pages (on the
alpha one page = 8k) */
for (i=0;i<81920;i++) a[i]=i*n; /* write to the array to force
it really to allocate*/
sleep(1<<n); /* sleep to make the process eating very few CPU
and avoid bombing the system with the fork */
fork();
n++; /*
}
and after having insmoded the page coloring module with verbosity at
maximum,I can see only 8 pages
allocated and coloured by the system and then nothing. The processes are
forked
and eat the memory (doing their job as they should) bypassing my patch
(as if it was not present),
that's why I suspect another mecanism is used. Am I wrong ?
thanks again for your help.
Sebastien
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Jan 31 2002 - 21:01:03 EST