Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932157AbbBTPGM (ORCPT ); Fri, 20 Feb 2015 10:06:12 -0500 Received: from www.linutronix.de ([62.245.132.108]:56802 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754004AbbBTPGK (ORCPT ); Fri, 20 Feb 2015 10:06:10 -0500 Message-ID: <54E74D5E.1050209@linutronix.de> Date: Fri, 20 Feb 2015 16:06:06 +0100 From: Sebastian Andrzej Siewior User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.4.0 MIME-Version: 1.0 To: Paolo Bonzini , Alexander Graf , Bogdan Purcareata , linuxppc-dev@lists.ozlabs.org, linux-rt-users@vger.kernel.org CC: linux-kernel@vger.kernel.org, scottwood@freescale.com, mihai.caraman@freescale.com, Thomas Gleixner Subject: Re: [PATCH 0/2] powerpc/kvm: Enable running guests on RT Linux References: <1424251955-308-1-git-send-email-bogdan.purcareata@freescale.com> <54E73A6C.9080500@suse.de> <54E740E7.5090806@redhat.com> <54E74A8C.30802@linutronix.de> <54E74B58.90706@redhat.com> In-Reply-To: <54E74B58.90706@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1615 Lines: 39 On 02/20/2015 03:57 PM, Paolo Bonzini wrote: > > > On 20/02/2015 15:54, Sebastian Andrzej Siewior wrote: >> Usually you see "scheduling while atomic" on -RT and convert them to >> raw locks if it is appropriate. >> >> Bogdan wrote in 2/2 that he needs to limit the number of CPUs in oder >> not cause a DoS and large latencies in the host. I haven't seen an >> answer to my why question. Because if the conversation leads to >> large latencies in the host then it does not look right. >> >> Each host PIC has a rawlock and does mostly just mask/unmask and the >> raw lock makes sure the value written is not mixed up due to >> preemption. >> This hardly increase latencies because the "locked" path is very short. >> If this conversation leads to higher latencies then the locked path is >> too long and hardly suitable to become a rawlock. > > Yes, but large latencies just mean the code has to be rewritten (x86 > doesn't anymore do event injection in an atomic regions for example). > Until it is, using raw_spin_lock is correct. It does not sound like it. It sounds more like disabling interrupts to get things run faster and then limit it on a different corner to not blow up everything. Max latencies was decreased "Max latency (us) 70 62" and that is why this is done? For 8 us and possible DoS in case there are too many cpus? > Paolo > Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/