Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH 4/4] ARCv2: entry: Reduce perf intr return path
To:     Peter Zijlstra <peterz@infradead.org>
CC:     <linux-snps-arc@lists.infradead.org>,
        <linux-kernel@vger.kernel.org>
Newsgroups: gmane.linux.kernel.arc,gmane.linux.kernel
References: <1510092784-19942-1-git-send-email-vgupta@synopsys.com>
 <1510092784-19942-5-git-send-email-vgupta@synopsys.com>
 <20171114102802.GA3165@worktop.lehotels.local>
 <8b2c70f0-fc51-fb9b-b799-9b85a3d3403b@gmail.com>
 <20171115101853.mtpamwkc5z4ptw2h@hirez.programming.kicks-ass.net>
From:   Vineet Gupta <Vineet.Gupta1@synopsys.com>
Message-ID: <4a28d9dc-b322-1a79-b1d1-c13db2f01ee7@synopsys.com>
Date:   Fri, 17 Nov 2017 15:42:50 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <20171115101853.mtpamwkc5z4ptw2h@hirez.programming.kicks-ass.net>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


>> But I was choosing to ignore it mainly to reduce the overhead of a
>> perf intr in general. A subsequent real interrupt could go thru thru
>> the gyrations of preemption etc.
> 
> So that's dangerous thinking... People that run a PREEMPT kernel
> generally tend to care about latency (esp. when combined with
> PREEMPT_RT).
> 
> And ignoring a preemption point gets these people upset (and missed
> preemptions are a royal friggin pain to debug).

Which implies that this patch goes to trash ! Unless we think that running 
instrumentation (perf) on production systems will not yield the same behavior in 
general.

>>> What do you (on ARC) do about irq_work ?
>>
>> Nothing ATM.

What I meant was lack of support for arch_irq_work_raise(). But given that we 
don't have NMIs (yet), this need *not* be a must as things could actually be 
scheduled in the regular intr return path ? At any rate arch_irq_work_raise() is 
not relevant for this discussion since NMIs are not involved.

> So the reason I'm asking is that some architectures that don't have NMIs
> call irq_work_run() at the very end of their perf-interrupt handler (ARM
> does this for instance).

But on ARC, we don't call irq_work_run() in perf intr return path and that seem to 
imply it is broken - as in latency to service a perf induced preemption.

> And the thing is, _that_ can and does do things like wakeups and will
> thus require doing the PREEMPT thing.

Reassures that this patch has to go to trash anyways, but I'm more worried about 
perf intr return for ARC in general.

>> Although I'm sure it is, can you please explain how irq_work is relevant in
>> the context of this patch.
> 
> Since the perf interrupt (in general) cannot call a whole lot of things
> for it needs to assume running from NMI context, it needs to defer
> things to a more regular context. It does this with irq_work.

And so do places such as flush_smp_call_function_queue() where the cross-core IPI 
could be an NMI.

> So for instance, when the output buffer reaches its watermark, we'll
> raise the irq_work to issue the wakeup of tasks that poll() on that.

Cool, thx for the explanation.
Perhaps I should put it in a Documentation/irq_work.txt pr some such !

Thx,
-Vineet

From 1584133581289283765@xxx Wed Nov 15 12:05:10 +0000 2017
X-GM-THRID: 1583482623170192100
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread