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 3376E92B for ; Thu, 15 Oct 2015 17:21:45 +0000 (UTC) Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7EE1A1BC for ; Thu, 15 Oct 2015 17:21:43 +0000 (UTC) Date: Thu, 15 Oct 2015 19:21:39 +0200 From: Jan Kara To: Steven Rostedt Message-ID: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151015111310.01903df1@gandalf.local.home> 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-10-15 11:13:10, Steven Rostedt wrote: > On Thu, 15 Oct 2015 09:22:58 -0500 (CDT) > Christoph Lameter wrote: > > > I have no particular use case for my company in mind here. This is what I > > hear when talking to various companies in a number of different areas of > > computing that have tried preempt_rt. > > Why are they telling you this and not us? Of course this may be people > that have different requirements. > > Need a few microsecond latencies; Try Xenomai. > Need a few hundred microsecond latencies; PREEMPT_RT will do > Need no interference from the kernel; Use NO_HZ_FULL > > Look, there's obviously users of PREEMPT_RT, so why are you trying to > kill it? If anything, PREEMPT_RT has made the mainline kernel cleaner. > > Just because you don't see a use for it, doesn't mean one does not > exist. 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? Honza -- Jan Kara SUSE Labs, CR