2 Replies Latest reply on May 2, 2011 10:29 PM by tedk

    L2 cache and LUT interaction


      If I am correct, the L2 cache uses 32-bit "physical" (from the P54C's perspective) addresses and only beyond the L2 cache the addresses are translated by the Mesh interface using the LUTs. Knowing this, and the fact that the L2 cache is write-back, I ran the following experiment;


      - I modified two LUT entries to give me some unused memory, inspired by the "Memory Hijacking" tutorial.

      - I allocated (through the /dev/mem device, using the mmap call), the two corresponding 16MB "LUT pages" in legacy mode, so they should be fully cached, write-back, not MPBT tagged, etc.

      - I read in and modify 256KB of consecutive data from the first LUT page to make sure it is in the L2 cache

      - I switch the LUT entry for my first page to point to the second LUT page

      - I 'flush' the L2 cache


      I then expected, as the cache is write-back, to see my (some, not necessarily all) modified cacheline data show up in the second LUT page. However, after inspecting the memory of both LUT pages with the sccGui, I saw that all modifications were actually in the original page. I ran the experiment multiple times, and got the same result. I've also verified with the sccGui tool that the LUT entries were correctly modified.


      So my question is this; can anyone help me explain this behavior?


      Does it take more time for a LUT switch to become 'active' ?

      Or is the L2 cache actually 34-bit indexed and not 32 bit?

      Or is the L2 cache actually doing write-through here?

        • 1. Re: L2 cache and LUT interaction

          After completing some more experiments, I've discovered the problem;


          Memory mapping from "/dev/mem" (for some unknown reason) does -NOT- give you L2 cached memory! This is a bit strange, as I thought this was supposed to be the 'legacy' mode of memory access, which was supposed to be L2 cached. This also makes me wonder if the memory assigned to normal programs is fully L2 cached or not.


          After changing my code to use "/dev/rckdcm", I did see the behavior I was expecting.

          • 2. Re: L2 cache and LUT interaction

            I think the LUT becomes active right away. It's 32-bit indexed.It's not write through.


            I've only done an mmap() on SCC using /dev/rckncm and /dev/rckdcm. I'm not sure what happens on the SCC if you mmap() from /dev/mem. I think you may be getting at the core's private memory.But I sent off some inquiries to our Linux developers.