COW optimization on exec

COW optimization on exec

[sidc7]

The Linux kernel uses the COW optimization for fork, so the processes share
the same pages, till on of the processes writes to the page. I was
wondering, if I do a fork and do an exec immediately following the fork,
will the COW optimization still be applied as it is most likely that the new
process is going to write to the shared pages? So doing a COW will not give
much benefit here, if it is done at all. Can anyone clarify if COW will be
applied in such a case, for e.g. a command shell.
-- 
View this message in context: http://www.nabble.com/COW-optimization-on-exec-tp22519639p22519639.html
Sent from the linux-kernel mailing list archive at Nabble.com.

Re: COW optimization on exec

[Johannes Weiner]

On Sat, Mar 14, 2009 at 07:57:54PM -0700, sidc7 wrote:
> 
> The Linux kernel uses the COW optimization for fork, so the processes share
> the same pages, till on of the processes writes to the page. I was
> wondering, if I do a fork and do an exec immediately following the fork,
> will the COW optimization still be applied as it is most likely that the new
> process is going to write to the shared pages? So doing a COW will not give
> much benefit here, if it is done at all. Can anyone clarify if COW will be
> applied in such a case, for e.g. a command shell.

COWing the pages is not much extrawork, it's handled with this code:

        /*
         * If it's a COW mapping, write protect it both
         * in the parent and the child
         */
        if (is_cow_mapping(vm_flags)) {
                ptep_set_wrprotect(src_mm, addr, src_pte);
                pte = pte_wrprotect(pte);
        }

you can find it in mm/memory.c::copy_one_pte().  The fault handler
will then take care of it (it will notice that the pte is
write-protected while the mapping itself allows writes) and then
replace the page with a copy in the faulting process.

The real overhead is copying the page tables in the first place.  But
the kernel can not know whether exec() is soon to be called, so fork()
always must provide the copy-whole-address-space semantics.

If the forking process knows in advance the child will exec
immediately, it can use vfork() which doesn't copy the address space.

	Hannes

Re: COW optimization on exec

[sidc7]

Thanks for clearing this


Johannes Weiner-5 wrote:
> 
> On Sat, Mar 14, 2009 at 07:57:54PM -0700, sidc7 wrote:
>> 
>> The Linux kernel uses the COW optimization for fork, so the processes
>> share
>> the same pages, till on of the processes writes to the page. I was
>> wondering, if I do a fork and do an exec immediately following the fork,
>> will the COW optimization still be applied as it is most likely that the
>> new
>> process is going to write to the shared pages? So doing a COW will not
>> give
>> much benefit here, if it is done at all. Can anyone clarify if COW will
>> be
>> applied in such a case, for e.g. a command shell.
> 
> COWing the pages is not much extrawork, it's handled with this code:
> 
>         /*
>          * If it's a COW mapping, write protect it both
>          * in the parent and the child
>          */
>         if (is_cow_mapping(vm_flags)) {
>                 ptep_set_wrprotect(src_mm, addr, src_pte);
>                 pte = pte_wrprotect(pte);
>         }
> 
> you can find it in mm/memory.c::copy_one_pte().  The fault handler
> will then take care of it (it will notice that the pte is
> write-protected while the mapping itself allows writes) and then
> replace the page with a copy in the faulting process.
> 
> The real overhead is copying the page tables in the first place.  But
> the kernel can not know whether exec() is soon to be called, so fork()
> always must provide the copy-whole-address-space semantics.
> 
> If the forking process knows in advance the child will exec
> immediately, it can use vfork() which doesn't copy the address space.
> 
> 	Hannes
> --
> 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/
> 
> 

-- 
View this message in context: http://www.nabble.com/COW-optimization-on-exec-tp22519639p22519869.html
Sent from the linux-kernel mailing list archive at Nabble.com.

Re: COW optimization on exec

[Nick Piggin]

On Sunday 15 March 2009 13:57:54 sidc7 wrote:
> The Linux kernel uses the COW optimization for fork, so the processes share
> the same pages, till on of the processes writes to the page. I was
> wondering, if I do a fork and do an exec immediately following the fork,
> will the COW optimization still be applied as it is most likely that the
> new process is going to write to the shared pages? So doing a COW will not

exec throws out all those pages, so go away without ever having been
copied. However it still costs memory CPU time TLB flushes etc in order
to set up the COW optimisation in the first place, so if you are doing
fork/exec, then I think vfork is the better option.

Re: COW optimization on exec

[sidc7]

> exec throws out all those pages, so go away without ever having been
> copied. However it still costs memory CPU time TLB flushes etc in order
> to set up the COW optimisation in the first place, so if you are doing
> fork/exec, then I think vfork is the better option.


Thanks once again, if I do something like creating an array spanning over
multiple pages, and then do a fork and in the child or the parent, write to
the array elements, this should result in an actual cow, where the OS will
actually do a copy of the pages as well in addition to the overhead required
for setting up COW in the first place?

Thanks


--
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/



-- 
View this message in context: http://www.nabble.com/COW-optimization-on-exec-tp22519639p22520422.html
Sent from the linux-kernel mailing list archive at Nabble.com.