Hello lkml,
I have a few questions about memory management:
When I do a fork, which part of the kernel is allocating the memory for
the childs, where and when the memory copy takes place ? I know that
linux is doing copy on write but I don't know which part of the kernel
is really doing the page allocation when the copy on write understands
that the process really wants to write now. Then the second question is
how is the memory copy done ?
The third and last question is what is the role of the slab allocator ?
When does a process asks for memory from a slab ? Is it used to build
the stack the heap ?
I have looked many web pages but none of them were clear to me.
If you have time, my whole problem is described here:
More context:
-------------
I am currently working to add page coloring into the linux kernel
version 2.2.19 (I am using Alpha with big direct mapped L1 so
page coloring is really necessary to have good stable perfs)
I started from a patch found on the web and it basically just
rewrapps some get_free_page calls to a get_free_page_by_address
routine that checks the virtual address and looks for a page which
is correctly aligned.
To sumup:
All calls to get_free_page in filemap.c have been replaced by
get_free_page_by_address
In memory.c the do_anonymous contains a get_free_page replaced by a
get_free_page_by_address
The patch is really doing nice job on simple cases (fortran monothread
code) but it fails on the following code:
{
char* a;
int i,n=0;
while(1)
{
a=malloc(sizeof(char)*1024*8*10); /*reserve ten pages (8k*10)
*/
for(i=0;i<81920;i++)
{
a[i]=i*n;
}
sleep (1<<n);
n++;
fork();
}
}
It simply fails because the page_coloring_code is bypassed when doing
forks... but
I could not find which part of the linux kernel code is doing the memory
allocations
for the forked processes.
thanks for any help
Sebastien
> When I do a fork, which part of the kernel is allocating the memory for
> the childs, where and when the memory copy takes place ? I know that
> linux is doing copy on write but I don't know which part of the kernel
> is really doing the page allocation when the copy on write understands
> that the process really wants to write now. Then the second question is
> how is the memory copy done ?
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.
Alan
>>>>> "Cabaniols" == Cabaniols, Sebastien <[email protected]> writes:
Cabaniols> When I do a fork, which part of the kernel is allocating the memory for
Cabaniols> the childs, where and when the memory copy takes place ?
mm/memory.c:copy_page_range()
It copies page tables and marks the ptes copy-on-write.
Cabaniols> I know that
Cabaniols> linux is doing copy on write but I don't know which part of the kernel
Cabaniols> is really doing the page allocation when the copy on write understands
Cabaniols> that the process really wants to write now. Then the second question is
Cabaniols> how is the memory copy done ?
mm/memory.c: handle_mm_fault()/handle_pte_fault() and do_wp_page()
Cabaniols> The third and last question is what is the role of the slab allocator ?
Cabaniols> When does a process asks for memory from a slab ? Is it used to build
Cabaniols> the stack the heap ?
Slab allocator is a memory allocation and caching mechanism for
(small) kernel objects. It is described in, e.g.,
http://nondot.org/sabre/os/files/MemManagement/SlabAllocator.pdf
Regards,
-velco
PS. You may also find help on irc.openprojects.net, #kernelnewbies
>>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
> 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 ?
As I said, its done by the page fault handler.