On 12/01/2014 10:22 AM, Christoph Lameter wrote: > 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. *snicker* :) There's also my old complaint that memory mapped files insist on periodically write-protecting their pages, causing unnecessary minor faults. This may or may not affect users, depending on the workload. FWIW, context tracking for full nohz is *slow*, so it may reduce noise, but it dramatically increases syscall and fault overhead. This isn't really an mm issue, though. --Andy > >> 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> > -- 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>