Re: [Lsf-pc] [LSF/MM ATTEND] Expanding OS noise suppression

[Andy Lutomirski <luto@amacapital.net>]

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@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
> 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>