4 ms·

I’m sorry, but I’m still not following… why must a cache be (in theory) flushed more often without overcommit?

• dekhn 5y ago
  if overcommit is disabled, then the system drops its internal caches (dentry cache, pagecache) to satisfy a memory allocation. Since most applications don't touch pages they allocate, that means the OS could have avoided dropping the caches. Since it did drop the caches, other parts of the system will then have to do more work to reconstruct the caches (looking up an dentry explicitly, or loading a page from disk instead of RAM). Everything I'm describing is about a busy server with heterogenous workloads of specific types.
  • wongarsu 5y ago
    I think what joosters is trying to say that instead of overcommitting a system could just allocate memory directly in swap. Both creating the page in swap and swapping it in on first write can be mostly optimized away apart from the bookkeeping, but you guarantee that you always have enough RAM+Swap to provide what you have committed to.
  • josefx 5y ago
    > if overcommit is disabled, then the system drops its internal caches (dentry cache, pagecache) to satisfy a memory allocation. Couldn't the system just reserve the pages for future use by the application but still use them for caching until the application actually tries to use them?
    • yc12340 5y ago
      This sounds like it would cause LRU caches to lose their LRU properties...
      • josefx 5y ago
        It doesn't need to reserve a specific page during allocation, just ensure that the number of reserved pages is smaller than the total amount of pages. I would expect at least read only caches to mostly behave like they currently do on a system with over commit enabled.