Re: hugepages will matter more in the future

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

 



On Mon, Apr 12, 2010 at 10:22:18AM +0200, Ingo Molnar wrote:
> 
> * Nick Piggin <npiggin@xxxxxxx> wrote:
> 
> > >  2) or we accept the fact that the application space is shifting to the
> > >     meta-kernels - and then we should agressively optimize Linux for those
> > >     meta-kernels and not pretend that they are 'specialized'. They literally
> > >     represent tens of thousands of applications apiece.
> > 
> > And if meta-kernels (or whatever you want to call a common or important 
> > workload) see some speedup that is deemed to be worth the cost of the patch, 
> > then it will probably get merged. Same as anything else.
> 
> I call a 'meta kernel' something that people code thousands of apps for, 
> instead of coding on the native kernel. JVM/DBs/Firefox are such frameworks. 
> (you can call it middleware i guess)
> 
> By all means they are not a 'single special-purpose workload' but represent 
> literally tens of thousands of apps.

I don't think I said anything like 'single special-purpose workload'. I
said 'common or important workload'. And they are not fundamentally
different (in context of evaluating and accepting a performance
improvement) than any other workload.

I'm not saying they don't matter.

The interesting fact is also that such type of thing is also much more
suitable for doing optimisation tricks. JVMs and RDBMS typically can
make use of hugepages already, for example.

--
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]