From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linutronix.de (146.0.238.70:993) by crypto-ml.lab.linutronix.de with IMAP4-SSL for ; 27 Jul 2018 09:17:35 -0000 Received: from mx2.suse.de ([195.135.220.15] helo=mx1.suse.de) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fiysN-0003ME-9L for speck@linutronix.de; Fri, 27 Jul 2018 11:17:34 +0200 Received: from relay1.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 2C733AD4D for ; Fri, 27 Jul 2018 09:17:24 +0000 (UTC) From: Nicolai Stange Subject: [MODERATED] Re: [RFC PATCH 4/6] kvm: handle host mode irqs 4 References: <6815cf025aa41954f911a1e76c2415035307b00f.1532339695.git.nstange@suse.de> <20180724152150.GQ2494@hirez.programming.kicks-ass.net> <87r2jrv8rn.fsf_-_@suse.de> <20180727074551.GX2494@hirez.programming.kicks-ass.net> Date: Fri, 27 Jul 2018 11:17:18 +0200 In-Reply-To: <20180727074551.GX2494@hirez.programming.kicks-ass.net> (speck for Peter Zijlstra's message of "Fri, 27 Jul 2018 09:45:51 +0200") Message-ID: <87in516ns1.fsf_-_@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: speck@linutronix.de List-ID: speck for Peter Zijlstra writes: > On Wed, Jul 25, 2018 at 01:45:32PM +0200, speck for Nicolai Stange wrote: >> So if nobody objects, I'll go with what Paolo proposed at [1]: replace >> the 'kernel_mode_irq_gen' counter with a latch flag and set that for any >> irq (but NMIs for a start). > > Well, the reason I suggested the other counters, is to avoid adding yet > another dirty cacheline to IRQs. Since we're already touching those > fields for most interrupts anyway.. might as well extend them to cover > what we need instead of adding more dirty lines. > Ah I see, that makes sense of course. I think there are two possible ways forward: 1.) Squeeze that new "kvm_cpu_l1tf_flush_l1d" latch flag into irq_cpustat_t. irq_cpustat_t is arch-specific and there is some room in its first cacheline, for example inserting up to four bytes right after ->irq_tlb_count wouldn't move anything critical out. 2.) Make the non-do_IRQ() irqs, i.e. smp_apic_timer_interrupt() & Co, call kstat_incr_irqs_this_cpu() and adapt arch_irq_stat_cpu() accordingly. Let vmx use struct kernel_stat ->irqs_sum as a irq generation counter as before. Pros 1.) - Easy to implement. - Doesn't rely on irq_domain drivers. Cons 1.) - Extra store from do_IRQ() irqs in comparison to 2.) - That "kvm_cpu_l1tf_flush_l1d" flag doesn't really qualify as an "IRQ stat" and it might be surprising to have it there. Pros 2.) - Might be cleaner, i.e. no random KVM specific flag in irq_cpustat_t. - Can perhaps be reused in non-KVM contexts, should there ever be a need for it. Cons 2.) - Slightly more implementation work, i.e. fiddling with arch_irq_stat_cpu(). - Relies on irq_domain drivers in that whatever they've installed at struct irq_desc ->handle_irq() does a kstat_incr_irqs_this_cpu(). I'm undecided. Thoughts? Thanks, Nicolai -- SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)