From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id CF7F8308 for ; Thu, 15 Oct 2015 18:14:52 +0000 (UTC) Received: from smtprelay.hostedemail.com (smtprelay0235.hostedemail.com [216.40.44.235]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 6990FAF for ; Thu, 15 Oct 2015 18:14:52 +0000 (UTC) Received: from smtprelay.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by smtpgrave02.hostedemail.com (Postfix) with ESMTP id C05F13636 for ; Thu, 15 Oct 2015 18:09:24 +0000 (UTC) Date: Thu, 15 Oct 2015 14:09:17 -0400 From: Steven Rostedt To: Jan Kara Message-ID: <20151015140917.26eb3306@gandalf.local.home> In-Reply-To: <20151015172139.GA14167@quack.suse.cz> References: <20151014092041.282117ac@gandalf.local.home> <20151014112225.26771952@gandalf.local.home> <20151014143244.19c2512a@gandalf.local.home> <20151015111310.01903df1@gandalf.local.home> <20151015172139.GA14167@quack.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Christoph Lameter , ksummit-discuss@lists.linuxfoundation.org Subject: Re: [Ksummit-discuss] [TECH TOPIC] Mainlining PREEMPT_RT List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Thu, 15 Oct 2015 19:21:39 +0200 Jan Kara wrote: > I know close to nothing about RT so maybe a stupid question: Do I > understand correctly that PREEMP_RT is there for use cases where processes > have latency requirements but also need to do syscalls as a part of their > work? Or is it that we cannot afford to isolate kernel on some CPUs because > it's too hard to estimate how much work it will need to do, it wastes too > much etc.? Or both? Yes, it's for processes that do syscalls, and also might share resources with non-rt threads. Isolating RT tasks on their own CPUs help, but what happens when you have more RT threads than CPUs? The deadline scheduler is also useful here, as it can guarantee that tasks get a specified amount of cpu time per period. PREEMPT_RT removes priority inversion, and lets tasks preempt pretty much anywhere in the kernel. Yes, if you have a single RT task with nothing else running on a CPU, it doesn't care about preemption, because it has nothing that it needs to preempt. If you can afford to place all your RT tasks on their own CPUs, then running either PREEMPT_NONE or PREEMPT_VOLUNTARY, and NO_HZ_FULL, is probably all that you need, as long as you don't have your RT tasks grabbing any mutex that could be held by a non RT task, or an RT task that shares the CPU with other RT tasks. -- Steve