1

Basically I'm wondering if a principle like cache locality, i.e. it's advantegous to access consecutive pieces of memory because usually bigger chunks of that memory are loaded into cache, also matters at the application level.

In practice - let's assume applications which don't require much extra allocations once started - I wonder if there is an advantage in starting application A and waiting a while, and then starting application B versus starting application A and B simultaneously. For the latter case I could imagine A requesting some memory, then B, then A again and so on (though I'm not sure it happens like that but on the other hand the OS cannot know on beforehand how much memory is going to be needed so it's not like it can reserve one big chunk on beforehand).

Is there a disadvantage to that, i.e. having the application memory consisting of multiple chunks at addresses further away from each other then what could theoretically be achieved if all application memory was allocated as one big chunk?

6
  • Running two processes at same time, will result in more cache misses, but will also benefit from better use of parallelisation (even on a single core, as disk and cpu are parallelised). Jun 29, 2016 at 8:07
  • What is your hypothesis? Is it that starting them together is better, or that starting them separately is better? Jun 29, 2016 at 8:10
  • @richard I don't really have an hypothesis as I don't know enough about the subject. My gut says starting them seperately would be better once they are started; I don't care about parallelism while starting.
    – stijn
    Jun 29, 2016 at 8:17
  • What operating system? What architecture? Jun 29, 2016 at 9:08
  • None specifically, linux/windows specific answers are ok
    – stijn
    Jun 29, 2016 at 18:11

1 Answer 1

1

Is there a disadvantage to that, i.e. having the application memory consisting of multiple chunks at addresses further away from each other then what could theoretically be achieved if all application memory was allocated as one big chunk?

You will have to:

  • look at what is virtual and physical memory, and how they are mapped.

  • see if caching is done at virtual or physical layer on your architecture.

  • see how your OS does things

Does fragmented physical memory matter? Only if it results in more complex virtual to physical maps (mmu, etc) A contiguous virtual block with non contiguous physical, may result in a much more complex lookup map. Linux has various page sizes that it can use, it will try to use the biggest it can (to best match the malloc). On my system Debian jessie with kernel 4.6.0-0 amd64, I have page sizes of 4k (154964 in use), 2M (3753 in use) and 1G (1 in use).

Does fragmented virtual memory matter? I can not see that it does, if the process requested several blocks with multiple malocs, then it will see them as separate, even if adjacent. One maloc must be contiguous in virtual. The security system, may but guard blocks between each maloced block, thus preventing them being adjacent.

On Linux a lot will be shared between processes: If the same executable file, then they will share all read-only blocks of the executable (text, data-ro, etc). They will also share initialised data (data), until one of them changes a page, then this page is copied. The same is done for all the dynamic linked libraries, so they will share a lot of these. Also the files on disk are the swap for this memory, so it will not bother reading in the data until it needs it (the program will start to run with none of it read in, this will result in a ram miss, and a page being read in, then the program will run, until there is another miss etc etc). If there is a lack of ram the a page can be dropped, it can be read again latter (no need to swap it out). This could cause a lot of disk reads when memory is low, resulting in slower start up. If processes are started separately, then the 2nd process putting pressure on the memory subsystem, will cause unused pages to be dropped (probably pages that were used at start up of process 1, but have not been used since).

(some architectures cache physical memory: this is the most obvious. Others cache virtual memory: this can result in the same physical memory being cached twice. This is wasteful, but simpler and faster. Some architectures do both e.g virtual caching at level 1, where it needs to be fast, physical caching at other levels where it needs to be memory efficient. ).

1
  • So the tldr; is bsically: shouldn't matter and it's hard to figure out if it does as there are many factors involved?
    – stijn
    Jun 29, 2016 at 18:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .