Re: cache coloring

[Dario Faggioli <dario.faggioli@citrix.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2972 bytes --]

On ven, 2013-11-22 at 18:30 +0100, Andrea Braschi wrote:
>         1. My "OS concepts" my be a bit rusty, but I only remember
>         something
>            called page coloring. Both Google and Wikipedia seems to
>         agree that
>            page and cache coloring are the same thing, but then I
>         don't
>            understand why you specifically mention L3 above. Can you
>         confirm
>            that it is this that you are after?
>            http://en.wikipedia.org/wiki/Cache_coloring
>         
>          http://www.freebsd.org/doc/en/articles/vm-design/page-coloring-optimizations.html
>         
> - yes is what i meant 
>
Ok.
>  
> 
> 
>         As far as I know (and as far as I'm able to grep :-)), I think
>         you
>         should start looking at xen/common/page_alloc.c.
>         
>         $ grep -i buddy xen/* -R
>         xen/arch/x86/x86_64/mm.c:     * buddy allocator relies on this
>         assumption.
>         xen/arch/x86/x86_64/mm.c:     * Mark the allocated page before
>         put free pages to buddy allocator
>         xen/common/page_alloc.c: * Simple buddy heap allocator for
>         Xen.
>         xen/common/page_alloc.c: * BINARY BUDDY ALLOCATOR
>         xen/common/page_alloc.c:/* Remove any offlined page in the
>         buddy pointed to by head. */
>         xen/common/page_alloc.c: * not freeing it to the buddy
>         allocator.
> 
> 
> yes i've already done it!...and after two days spent at looking at
> xen/common/page_alloc.c I was wondering if it was the right chunck of
> code
> (I was also been digging through a lot of mm.c...) 
>
Sure. Well, for stuff related to the memory allocator, I really think
that's what you are looking for.

Why were you thinking that it could not be?

>         This is a nice guide/checklist:
>          http://wiki.xenproject.org/wiki/Asking_Xen_Devel_Questions
>         
> Ok thanks, i'll be more specific as soon as I can! by now i really
> thank you for the attention, soon I'll be more precise!
> 
Sure! :-)

Oh, sorry if insist, but you didn't mention why 4.2.3 and not the
upstream git repo:

 http://xenbits.xen.org/gitweb/?p=xen.git;a=summary

(look at the staging branch).

I'm asking because, if you'll end up with something sensible, something
that brings some nice performances improvements, it would be great to
integrate in in Xen upstream, and that would be a lot easier if you work
with the latest upstream, rather than with a specific (especially if a
quite old) version.

If you need help in understanding what "work with the latest upstream"
means, I'm sure we can help. :-)

Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel