From: Christoph Lameter <clameter@sgi.com> Date: Wed, 26 Mar 2008 10:56:17 -0700 (PDT)Actually, ever since gcc went to a garbage collecting allocator, I've found it to be a TLB thrasher. It will repeatedly randomly walk over a GC pool of at least 8MB in size, which to fit fully in the TLB with 4K pages reaquires a TLB with 2048 entries assuming gcc touches no other data which is of course a false assumption. For some compiles this GC pool is more than 100MB in size. GCC does not fit into any modern TLB using it's base page size. --
| Mark Lord | Re: Linux 2.6.24-rc7 |
| Kentaro Takeda | [TOMOYO 05/15](repost) Domain transition handler functions. |
| Willy Tarreau | Re: Linux v2.6.24-rc1 |
| Al Boldi | [RFD] Incremental fsck |
| drew | Re: SVGA-alphanum. modes |
| Kevin Cummings | VESA video support during boot. |
| Raymond Nijssen | Re: What the 17" monitor reviews never tell you |
| Michael Haardt | GNU shell utils 1.7: date(1) dumps core (with easy solution:) |
git: | |
| David Woodhouse | Re: [bug?] tg3: Failed to load firmware "tigon/tg3_tso.bin" |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Jarek Poplawski | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Jarek Poplawski | Re: [BUG] New Kernel Bugs |
