Re: [PATCH 00 of 41] Transparent Hugepage Support #17

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

 



On Tue, 6 Apr 2010, Avi Kivity wrote:

> On 04/06/2010 07:50 PM, Andrea Arcangeli wrote:
> > On Tue, Apr 06, 2010 at 11:45:39PM +1000, Nick Piggin wrote:
> >
> > > problems. Speedups like Linus is talking about would refer to ways to
> > > speed up actual workloads, not ways to avoid fundamental limitations.
> > >
> > > Prefetching, memory parallelism, caches. It's worked for 25 years :)
> > >
> > This will always give you a worst case additional 6% on top (gcc is a
> > definitive worst case) of all other speedup of the actual workloads,
> > for server loads more likely>=15% boost. It's plain underclocking
> > your CPU not to run this.
> >
>
> I don't think gcc is worst case.  Workloads that benefit from large pages are
> those with bloated working sets that do a lot of pointer chasing and do little
> computation in between.  gcc fits two out of three (just a partial score on
> the first).

Once you have huge pages you will likely start to optimize for locality.

Pointer chasing is bad even with huge pages if you go between multiple
huge pages and you are beyond the number of huge tlb entries supported by
the cpu.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxxx  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]