On Mon, 1 Dec 2014, Rik van Riel wrote: > This is a very interesting topic, but I am not sure the right audience > for many of these discussions will be at LSF/MM... Well some of it at least is relevant. > Besides the minor and major faults, and the THP related defragmentation, > which of the problems could actually be addressed by the memory > management subsystem? One of the motivations for the development of SLUB for example was the long periods of latency generated by SLAB's object expiration. There are numerous code segment in the mm subsystem that can cause suprisingly long latencies for the application. Memory allocations through the page allocator are on of the most severe examples. The SLUB allocator's per cpu partial pages introduce some new latencies (not as bad as SLAB but still) and I have seen that RT people compile that cpu partial page support out because it causes higher variability. Some way for the application to know and be able to avoid these would be great. > Would you have a list of other items in the memory management subsystem > that cause latency issues? I mentioned some above. There are numeous issues arising from various pieces of heavy operations of the mm subsystems which involve page migration, writeback, general page table walks, statistics keeping etc etc. > Is the minor & major fault thing an actual problem for people with real > time applications? Yes. The timeframes for electronic trading are lower than the time it takes for a fault to be processed. A fault occurring at the wrong time causes an immediate hit on the bottom line. > Do you have any ideas on how we could solve the defragmentation and THP > issue? Even strawman proposals to start a discussion could be useful... Right now we disable automatic defrag and do a run of defrag and THP before the start of business manually. There are cores that are dedicated for the OS where the defrag etc can run during business hours and which could also do these jobs remotely for the low latency cores if one is careful and does not create too many latency issues on the remote cores. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>