6 ms·

I've read this article before, and I have no idea why anyone would think that page alignment is a good idea, unless you're doing kernel-level stuff that absolut

by TillE 12y ago

I've read this article before, and I have no idea why anyone would think that page alignment is a good idea, unless you're doing kernel-level stuff that absolutely requires it. Optimization for performance has always been about cache lines (64 bytes), not pages (4 KiB). Of course you're going to get terrible results when you're wasting huge amounts of memory.

somerandomone 12y ago
It's probably because if your data is spanned across two pages, it may require a lot of page swaps if you access data back and forth?
- TrainedMonkey 12y ago
  I think your premise is correct, if our data all on one page we only need to fetch one page. If we write anything back, only one page needs to be updated. In case of two pages, read/write work doubles.
  - MichaelGG 12y ago
    And the prefetcher cannot fetch across page boundaries since that might fault.
    - TheLoneWolfling 12y ago
      This seems like a hardware flaw to me. We can do OoO execution, why can't we do OoO prefetching w.r.t. page faults? (I.e. try to fetch into a cache, if there would be a page fault don't. If there's something that would cause that fetch to page fault between it being prefetched and it logically being fetched, invalidate the cace.)
      - thesz 12y ago
        This was actually done in some early DEC Alphas, I believe. OoO engine were able to issue address calculation from loads (if address register is ready) ahead and thusly when real load instruction execute the data is already in cache or closer to cache. It is really easy to do, actually. It can even simplify page fault handling in CPU.
- deleted 12y ago
  [deleted]
- deleted 12y ago
  [deleted]
- teraflop 12y ago
  But data is transferred between the CPU and RAM in units of cache lines, not pages.
  - mattgodbolt 12y ago
    This is correct: the posts above referring to "page swaps" are a little misleading. The only reason I can think of to keep things within one page is to reduce the load on the TLB, which caches logical-to-physical addresses and which has the granularity of a page. That being said if you're really looking to optimize for TLB misses you should be using huge pages if your OS and processor support them.
    - solarexplorer 12y ago
      When you want to minimize transfers between disk and ram and your OS does paging, then it makes sense to put unfrequently used data (like error messages) together in a page with other unfrequently used data. It's mostly what you would do on a cache line level (instead of a page level) to minimize transfers between main memory and cache.
solarexplorer 12y ago
Well, aligning for words or cache lines is good. Aligning for pages not so much. Of course this has been known for ages, but sometimes it is hard to avoid, e.g. inside the Linux Kernel: http://yarchive.net/comp/cache_thrashing.html http://yarchive.net/comp/cache_thrashing.html
caf 12y ago
You're not wrong, but it is quite possible that you might accidentally end up with page-alignment without realising it, such as if your `malloc()` is backed by `mmap()`.
- colanderman 12y ago
  This is easier than one would think. Say you have many large shared-memory regions (e.g. queues) with control structures at the start. Bam, all those control structures, and therefore your atomic accesses, are now sharing cache lines.

by TillE 12y ago

somerandomone 12y ago

It's probably because if your data is spanned across two pages, it may require a lot of page swaps if you access data back and forth?

TrainedMonkey 12y ago
I think your premise is correct, if our data all on one page we only need to fetch one page. If we write anything back, only one page needs to be updated. In case of two pages, read/write work doubles.
- MichaelGG 12y ago
  And the prefetcher cannot fetch across page boundaries since that might fault.
  - TheLoneWolfling 12y ago
    This seems like a hardware flaw to me. We can do OoO execution, why can't we do OoO prefetching w.r.t. page faults? (I.e. try to fetch into a cache, if there would be a page fault don't. If there's something that would cause that fetch to page fault between it being prefetched and it logically being fetched, invalidate the cace.)
    - thesz 12y ago
      This was actually done in some early DEC Alphas, I believe. OoO engine were able to issue address calculation from loads (if address register is ready) ahead and thusly when real load instruction execute the data is already in cache or closer to cache. It is really easy to do, actually. It can even simplify page fault handling in CPU.
deleted 12y ago
[deleted]
deleted 12y ago
[deleted]
teraflop 12y ago
But data is transferred between the CPU and RAM in units of cache lines, not pages.
- mattgodbolt 12y ago
  This is correct: the posts above referring to "page swaps" are a little misleading. The only reason I can think of to keep things within one page is to reduce the load on the TLB, which caches logical-to-physical addresses and which has the granularity of a page. That being said if you're really looking to optimize for TLB misses you should be using huge pages if your OS and processor support them.
  - solarexplorer 12y ago
    When you want to minimize transfers between disk and ram and your OS does paging, then it makes sense to put unfrequently used data (like error messages) together in a page with other unfrequently used data. It's mostly what you would do on a cache line level (instead of a page level) to minimize transfers between main memory and cache.

solarexplorer 12y ago

Well, aligning for words or cache lines is good. Aligning for pages not so much. Of course this has been known for ages, but sometimes it is hard to avoid, e.g. inside the Linux Kernel: http://yarchive.net/comp/cache_thrashing.html http://yarchive.net/comp/cache_thrashing.html

caf 12y ago

You're not wrong, but it is quite possible that you might accidentally end up with page-alignment without realising it, such as if your `malloc()` is backed by `mmap()`.

colanderman 12y ago
This is easier than one would think. Say you have many large shared-memory regions (e.g. queues) with control structures at the start. Bam, all those control structures, and therefore your atomic accesses, are now sharing cache lines.