From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pd0-f170.google.com (mail-pd0-f170.google.com [209.85.192.170]) by kanga.kvack.org (Postfix) with ESMTP id 1404A6B0038 for ; Tue, 2 Dec 2014 20:32:05 -0500 (EST) Received: by mail-pd0-f170.google.com with SMTP id fp1so14376387pdb.1 for ; Tue, 02 Dec 2014 17:32:04 -0800 (PST) Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com. [209.85.220.43]) by mx.google.com with ESMTPS id ey6si14415024pab.160.2014.12.02.17.32.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Dec 2014 17:32:03 -0800 (PST) Received: by mail-pa0-f43.google.com with SMTP id kx10so14693708pab.2 for ; Tue, 02 Dec 2014 17:32:03 -0800 (PST) Message-ID: <547E680F.4080108@amacapital.net> Date: Tue, 02 Dec 2014 17:31:59 -0800 From: Andy Lutomirski MIME-Version: 1.0 Subject: Re: [Lsf-pc] [LSF/MM ATTEND] Expanding OS noise suppression References: <547CA12A.6010102@redhat.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Sender: owner-linux-mm@kvack.org List-ID: To: Christoph Lameter , Rik van Riel Cc: lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org, "Paul E. McKenney" , Frederic Weisbecker 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: email@kvack.org > -- 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: email@kvack.org