17:21 <mrcasu> I replied to your second email, you touched a very critical point
17:40 <kota> I'll reply later
17:40 <kota> what worries me is that once you're using a local bank
17:40 <kota> you're giving up a quarter of the address space
17:41 <kota> (one out of the four permutations of bits 13 and 14 will always be handled through the local bank)
17:42 -!- mrcasu [mrcasu@gmail.com] has quit [Leaving...]
17:42 <kota> so yes, we could rent something as big as we wanted.. but accessing it wouldn't be sequential
17:44 <mrcasu> well, you can opt for not having local bank
17:44 <mrcasu> you can redirect all of your traffic to remote banks
17:45 <mrcasu> what you can't have is the WHOLE 4 banks pluse remote banks
17:45 <mrcasu> if you use four local banks you're done, you can't have any more remote banks
17:46 <mrcasu> what do you mean "wouldn't be sequential"
17:47 <kota> yeah if say Im using the local bank 0
17:47 <kota> any address request whose 13th-14th bits are "00"
17:47 <kota> will be cached on the local bank
17:47 <mrcasu> right
17:48 <mrcasu> that's true if you remapped your address bits 14:13 to that bank
17:48 <mrcasu> you can also remap 14-13 00 to bank 1 2 and 3
17:48 <mrcasu> sorry to bank 1 xor 2 xor 3
17:49 <kota> yes, I need to pick one
17:50 <mrcasu> you can merge 00 01 and 10 on one bank and leave out 11 for another bank, e.g. the remote one
17:51 <kota> so if I'm using that local bank, plus some other (much bigger) remote banks, when I access my data structure (say a huge array of 1MB), one out of four
sequential reads will go through the local bank (and most likely will cause a cache miss)
17:51 <kota> this of course will happen in groups of 2**13 accesses
17:52 <mrcasu> well, that's typical for any NUCA architecture
17:53 <kota> it's hell to code for that! haha
17:53 <kota> to get a decent performance you'd really need to know low-level details
17:54 <kota> such as which local/remote banks you're renting
17:54 <mrcasu> i don't totally agree, having a remote bank on-chip is always better than missing and accessing a slow off-chip memory
17:55 <kota> true that, it's better than nothing
17:56 <kota> but if you want to minimise off-chip accesses, and you're renting caches of different sizes, you need to know probably too much (from the programmer's
perspective)
17:57 <mrcasu> True, but maybe the HW can assist the code with performance counters and dynamic relocation of caches. But anyway, that's not our focus now, our focus is to
use this in a smart way for having accelerators communicate with cores
18:00 <kota> agreed
18:08 <kota> do you have time tonite to commit any of your C code in soft/? I have a preliminary lib to send RDV messages ready
18:08 <kota> would like to commit it tonite as well
18:09 <mrcasu> yes, I will push the code for test_memory and a makefile, you will need to put the tool chain for plasma
18:10 <kota> ok
18:10 <kota> I guess I'll assign an environment variable for the compiler
18:10 <kota> probably there's a fairly standard one for that
18:10 -!- mrcasu [mrcasu@gmail.com] has quit [Leaving...]
18:18 <mrcasu> committed, can you pls check?
18:32 -!- mrcasu [mrcasu@gmail.com] has quit [Leaving...]
18:36 <mrcasu> talk to you tomorrow, bye for now, keep pushing!!!!
18:37 -!- mrcasu [mrcasu@gmail.com] has quit [Leaving...]