[PATCH] Avoid ggc_collect () after WPA forking

Martin Liška mliska@suse.cz
Wed Mar 19 15:13:00 GMT 2014


On 03/19/2014 03:55 PM, Richard Biener wrote:
> On Wed, 19 Mar 2014, Martin Liška wrote:
>
>> There are stats for Firefox with LTO and -O2. According to graphs it
>> looks that memory consumption for parallel WPA phase is similar.
>> When I disable parallel WPA, wpa footprint is ~4GB, but ltrans memory
>> footprint is similar to parallel WPA that reduces libxul.so linking by ~10%.
> Ok, so I suppose this tracks RSS, not virtual memory use (what is
> "used" and what is "active")?

Data are given by vmstat, according to: 
http://stackoverflow.com/questions/18529723/what-is-active-memory-and-inactive-memory

*Active memory*is memory that is being used by a particular process.
*Inactive memory*is memory that was allocated to a process that is no 
longer running.

So please follow just 'blue' line that displays really used memory. 
According to man, vmstat tracks virtual memory statistics.

> And it is WPA plus LTRANS stages, WPA ends where memory use first goes
> down to zero?
> I wonder if you can identify the point where parallel streaming
> starts and where it ends ... ;)

Exactly, WPA ends when it goes to zero.

> Btw, I have another patch in my local tree, limiting the
> exponential growth of blocks we allocate when outputting sections.
> But it shouldn't be _that_ bad ... maybe you can try if it has
> any effect?

I can apply it.

Martin

>
> Thanks,
> Richard.
>
> Index: gcc/lto-section-out.c
> ===================================================================
> --- gcc/lto-section-out.c	(revision 208642)
> +++ gcc/lto-section-out.c	(working copy)
> @@ -99,13 +99,19 @@ lto_end_section (void)
>   }
>   
>   
> +/* We exponentially grow the size of the blocks as we need to make
> +   room for more data to be written.  Start with a single page and go up
> +   to 2MB pages for this.  */
> +#define FIRST_BLOCK_SIZE 4096
> +#define MAX_BLOCK_SIZE (2 * 1024 * 1024)
> +
>   /* Write all of the chars in OBS to the assembler.  Recycle the blocks
>      in obs as this is being done.  */
>   
>   void
>   lto_write_stream (struct lto_output_stream *obs)
>   {
> -  unsigned int block_size = 1024;
> +  unsigned int block_size = FIRST_BLOCK_SIZE;
>     struct lto_char_ptr_base *block;
>     struct lto_char_ptr_base *next_block;
>     if (!obs->first_block)
> @@ -135,6 +141,7 @@ lto_write_stream (struct lto_output_stre
>         else
>   	lang_hooks.lto.append_data (base, num_chars, block);
>         block_size *= 2;
> +      block_size = MIN (MAX_BLOCK_SIZE, block_size);
>       }
>   }
>   
> @@ -152,7 +159,7 @@ lto_append_block (struct lto_output_stre
>       {
>         /* This is the first time the stream has been written
>   	 into.  */
> -      obs->block_size = 1024;
> +      obs->block_size = FIRST_BLOCK_SIZE;
>         new_block = (struct lto_char_ptr_base*) xmalloc (obs->block_size);
>         obs->first_block = new_block;
>       }
> @@ -162,6 +169,7 @@ lto_append_block (struct lto_output_stre
>         /* Get a new block that is twice as big as the last block
>   	 and link it into the list.  */
>         obs->block_size *= 2;
> +      obs->block_size = MIN (MAX_BLOCK_SIZE, obs->block_size);
>         new_block = (struct lto_char_ptr_base*) xmalloc (obs->block_size);
>         /* The first bytes of the block are reserved as a pointer to
>   	 the next block.  Set the chain of the full block to the



More information about the Gcc-patches mailing list