Re: [PATCH] RFC: Cache LTO streamer mappings

2011-10-12 Thread Diego Novillo
On Sun, Oct 9, 2011 at 13:11, Andi Kleen a...@firstfloor.org wrote: Is it still a good idea? Given that you found no speedups and it introduces added complexity, I think it's best if we revisit the idea later. I never found bytecode reading to be a bottleneck in LTO, but perhaps Jan can

Re: [PATCH] RFC: Cache LTO streamer mappings

2011-10-12 Thread Diego Novillo
On 11-10-12 08:25 , Jan Hubicka wrote: WPA is currently about 1/3 of readingtype merging, 1/3 of streaming out and 1/3 of inlining. inlining is relatively easy to cure, so yes, streaming performance is important. The very basic streaming primitives actualy still shows top in profile along

Re: [PATCH] RFC: Cache LTO streamer mappings

2011-10-12 Thread Jan Hubicka
On 11-10-12 08:25 , Jan Hubicka wrote: WPA is currently about 1/3 of readingtype merging, 1/3 of streaming out and 1/3 of inlining. inlining is relatively easy to cure, so yes, streaming performance is important. The very basic streaming primitives actualy still shows top in profile along

[PATCH] RFC: Cache LTO streamer mappings

2011-10-09 Thread Andi Kleen
From: Andi Kleen a...@linux.intel.com Currently the LTO file mappings use a simple one-off cache. This doesn't match the access pattern very well. This patch adds a real LRU of LTO mappings with a total limit. Each file is completely mapped now instead of only specific sections. This addresses