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 ; 29 Jul 2018 20:06:15 -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 1fjrro-0006rW-4b for speck@linutronix.de; Sun, 29 Jul 2018 22:00:36 +0200 Received: from relay1.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id E78A6AEE2 for ; Sun, 29 Jul 2018 20:00:30 +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> <87in516ns1.fsf_-_@suse.de> Date: Sun, 29 Jul 2018 22:00:22 +0200 In-Reply-To: (speck for Paolo Bonzini's message of "Fri, 27 Jul 2018 11:55:56 +0200") Message-ID: <87fu01ak2x.fsf_-_@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: speck for Paolo Bonzini writes: > On 27/07/2018 11:17, speck for Nicolai Stange wrote: >> 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. > > There's precedent for this, for example __softirq_pending. In fact you > could reduce __softirq_pending to an u16 and not increase the size of > irq_cpustat_t, since there are <16 softirqs. Perfect, thanks! Nicolai