Re: Does the copy-on-write usually happen on application startup?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Jim,


--- Jim Cromie <jcromie@xxxxxxxxxx> escreveu:

> Rik van Riel wrote:
> 
> >On Tue, 14 Jun 2005, Jim Cromie wrote:
> >
> >  
> >
> >>IIUC, only fork sets up the new process with
> COW-able pages, which may 
> >>or may not be copied-on-write, dependent upon
> whether a write happens to 
> >>a given page.
> >>    
> >>
> >
> >There's an additional source for COW pages:
> MAP_PRIVATE mmap
> >of files, especially shared libraries.  When an
> application
> >maps a shared library, this is done with a writable
> MAP_PRIVATE
> >mmap.  This means that the application can write to
> the mmaped
> >region, but the writes will not be written back to
> the file.
> >
> >Instead, the writes will go to a private copy of
> the page
> >that was dirtied.  A COW page...
> >
> >  
> >
> is this a common thing ? 
> or, why would shared-libs be written to, except for
> self-modifying code ?
> linking of dynamically loaded libs ( ie loaded
> mid-run ) ?
> 
> heres the /proc/$$/maps taken from a bash shell.
> 
> [root@harpo 6761]# more maps
> 00a6e000-00a83000 r-xp 00000000 03:02 2125172   
> /lib/ld-2.3.5.so
> 00a84000-00a85000 r-xp 00015000 03:02 2125172   
> /lib/ld-2.3.5.so
> 00a85000-00a86000 rwxp 00016000 03:02 2125172   
> /lib/ld-2.3.5.so
> 00a88000-00bab000 r-xp 00000000 03:02 2125180   
> /lib/tls/libc-2.3.5.so
> 00bab000-00bac000 --xp 00123000 03:02 2125180   
> /lib/tls/libc-2.3.5.so
> 00bac000-00bae000 r-xp 00123000 03:02 2125180   
> /lib/tls/libc-2.3.5.so
> 00bae000-00bb0000 rwxp 00125000 03:02 2125180   
> /lib/tls/libc-2.3.5.so
> 00bb0000-00bb2000 rwxp 00bb0000 00:00 0
> 00bd9000-00bdb000 r-xp 00000000 03:02 2126327   
> /lib/libdl-2.3.5.so
> 00bdb000-00bdc000 r-xp 00001000 03:02 2126327   
> /lib/libdl-2.3.5.so
> 00bdc000-00bdd000 rwxp 00002000 03:02 2126327   
> /lib/libdl-2.3.5.so
> 00dbe000-00dc1000 r-xp 00000000 03:02 2126336   
> /lib/libtermcap.so.2.0.8
> 00dc1000-00dc2000 rwxp 00002000 03:02 2126336   
> /lib/libtermcap.so.2.0.8
> 08047000-080d8000 r-xp 00000000 03:02 659092    
> /bin/bash
> 080d8000-080de000 rwxp 00090000 03:02 659092    
> /bin/bash
> 080de000-080e3000 rwxp 080de000 00:00 0
> 09b20000-09b62000 rwxp 09b20000 00:00 0         
> [heap]
> b7d80000-b7d89000 r-xp 00000000 03:02 2121646   
> /lib/libnss_files-2.3.5.so
> b7d89000-b7d8a000 r-xp 00008000 03:02 2121646   
> /lib/libnss_files-2.3.5.so
> b7d8a000-b7d8b000 rwxp 00009000 03:02 2121646   
> /lib/libnss_files-2.3.5.so
> b7d9e000-b7da0000 rwxp b7d9e000 00:00 0
> b7da0000-b7da6000 r-xs 00000000 03:02 39351      
> /usr/lib/gconv/gconv-modules.cache
> b7da6000-b7fa6000 r-xp 00000000 03:02 2532494    
> /usr/lib/locale/locale-archive
> b7fa6000-b7fa8000 rwxp b7fa6000 00:00 0
> b7fc3000-b7fc4000 r-xp b7fc3000 00:00 0
> bfdaf000-bfdc4000 rw-p bfdaf000 00:00 0         
> [stack]
> 
> 
> I presume all the w pages are COW-able
> 
> to try to answer myself, I did this:
> 
> [root@harpo proc]# more 6761/maps |wc
>      26     151    1669
> [root@harpo proc]# sort {6697,6761}/maps |wc
>      52     302    3338
> [root@harpo proc]# sort -u {6697,6761}/maps |wc
>      36     208    2297
> 

The pid 6697 and 6761 are not sharing the same VMAs,
right?


Do you know anyway to track cow pages based on maps
informations among processes that share the same VMAs?

For instance, the firefox browser has some processes
inside the /proc/pid/task and AFAIK the pids under
this directory share the same VMAs. You can see those
information through maps for each pid.

So, any idea about cow pages among processes that
share same VMAs?

BR,

Mauricio Lin.

> so 5 mappings in each process have apparently been
> altered,
> unsprisingly including [heap] and [stack]
> The rest of the COW-able maps havent been COW-ed
> yet.
> 
> 09b20000-09b62000 rwxp 09b20000 00:00 0         
> [heap]
> 09b96000-09bd8000 rwxp 09b96000 00:00 0         
> [heap]
> b7d2a000-b7d30000 r-xs 00000000 03:02 39351      
> /usr/lib/gconv/gconv-modules.cache
> b7d30000-b7f30000 r-xp 00000000 03:02 2532494    
> /usr/lib/locale/locale-archive
> b7da0000-b7da6000 r-xs 00000000 03:02 39351      
> /usr/lib/gconv/gconv-modules.cache
> b7da6000-b7fa6000 r-xp 00000000 03:02 2532494    
> /usr/lib/locale/locale-archive
> b7f30000-b7f32000 rwxp b7f30000 00:00 0
> b7f4d000-b7f4e000 r-xp b7f4d000 00:00 0
> b7fa6000-b7fa8000 rwxp b7fa6000 00:00 0
> b7fc3000-b7fc4000 r-xp b7fc3000 00:00 0
> bfd39000-bfd4e000 rw-p bfd39000 00:00 0         
> [stack]
> bfdaf000-bfdc4000 rw-p bfdaf000 00:00 0         
> [stack]
> 
> I can see why a cache is COW-ed, but why a
> locale-archive ?
> and what are those nameless maps ?
> 
> For everyone else reading along, the questions may
> be dumb, but the
> answers are *authorititative*
> 



	
	
		
____________________________________________________
Yahoo! Mail, cada vez melhor: agora com 1GB de espaço grátis! http://mail.yahoo.com.br

--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive:       http://mail.nl.linux.org/kernelnewbies/
FAQ:           http://kernelnewbies.org/faq/


[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux