From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755538AbcHVQlk (ORCPT ); Mon, 22 Aug 2016 12:41:40 -0400 Received: from smtp81.iad3a.emailsrvr.com ([173.203.187.81]:44729 "EHLO smtp81.iad3a.emailsrvr.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753243AbcHVQlj (ORCPT ); Mon, 22 Aug 2016 12:41:39 -0400 X-Greylist: delayed 352 seconds by postgrey-1.27 at vger.kernel.org; Mon, 22 Aug 2016 12:41:38 EDT X-SMTPDoctor-Processed: csmtpprox beta X-Auth-ID: markh@compro.net X-Sender-Id: markh@compro.net Reply-To: markh@compro.net Subject: Re: Context switch latency in tickless isolated CPU References: <86f3248c-defd-f200-9eb6-bdf420771745@mellanox.com> <20160819123437.GE10121@twins.programming.kicks-ass.net> <20160821145302.GP3482@linux.vnet.ibm.com> <20160822144804.GB3482@linux.vnet.ibm.com> <5e71b00a-fe6c-6fbe-6a04-d62e96f9e1ba@compro.net> <20160822153714.GC3482@linux.vnet.ibm.com> To: paulmck@linux.vnet.ibm.com Cc: GeHao Kang , Peter Zijlstra , Chris Metcalf , =?UTF-8?B?RnLDqWTDqXJpYyBXZWlzYmVja2Vy?= , linux-api@vger.kernel.org, linux-kernel@vger.kernel.org, tglx@linutronix.de, mingo@kernel.org From: Mark Hounschell Organization: Compro Computer Svcs. Message-ID: <205710c7-774c-0f9d-c336-72da56844646@compro.net> Date: Mon, 22 Aug 2016 12:35:44 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2 MIME-Version: 1.0 In-Reply-To: <20160822153714.GC3482@linux.vnet.ibm.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08/22/2016 11:37 AM, Paul E. McKenney wrote: > On Mon, Aug 22, 2016 at 11:12:45AM -0400, Mark Hounschell wrote: >> On 08/22/2016 10:48 AM, Paul E. McKenney wrote: >>> On Mon, Aug 22, 2016 at 05:40:03PM +0800, GeHao Kang wrote: >>>> On Sun, Aug 21, 2016 at 10:53 PM, Paul E. McKenney >>>> wrote: >>>>> If latency is all you care about, one approach is to map the device >>>>> registers into userspace and do the I/O without assistance from the >>>>> kernel. >>>> In addition to the context switch latency, local interrupts are also >>>> closed during >>>> user_enter and user_exit of the context tracking. Therefore, the interrupt >>>> latency might be also increased on the isolated tickless CPU. That >>>> will degrade the >>>> real time performance. Are these two events determined? >>> >>> Hmmm... Why would you be taking interrupts on your isolated tickless >>> CPUs? Doesn't that defeat the purpose of designating them as isolated >>> and tickless? >> >> Don't mean to butt in here but think about a "special" PCI card that >> does nothing but take an external interrupt or external interrupts >> from an outside source where the latency between the time it occurs >> on the outside and the time an isolated processor can act on that >> event. The IRQ of that card also being pinned/isolated to that >> processor. This is a very common thing in the RT world. > > In this case, the host OS would see an event-driven real-time workload > from the PCI card, which would lead me to suggest -not- using NO_HZ_FULL > on the host OS. > > Of course, if you are instead building an OS to run on the PCI card > itself, then the choice of configuration would depend on how the PCI > card was set up. If it polled hardware, then NO_HZ_FULL on the PCI card > might work quite well. But then you wouldn't have interrupts (on the > PCI card), so I am guessing that you mean the scenario covered in the > first paragraph. > > Or am I missing your point? > > Thanx, Paul > First paragraph scenario is the one I was referring. Thanks Mark >> Mark >> >>> The key point being that effective use of NO_HZ_FULL requires >>> careful configuration and complete understanding of your workload. >>> And it is quite possible that you instead need to use something >>> other than NO_HZ_FULL. >>> >>> If your question is instead "why must interrupts be disabled during >>> context tracking", I must defer to people who understand the x86 >>> entry/exit code paths better than I do. >>> >>> Thanx, Paul >>> >>> >> > >