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

[Christoph Lameter <cl@linux.com>]

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@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>