Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752155AbbBWHui (ORCPT ); Mon, 23 Feb 2015 02:50:38 -0500 Received: from mail-bl2on0107.outbound.protection.outlook.com ([65.55.169.107]:62880 "EHLO na01-bl2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751174AbbBWHuh (ORCPT ); Mon, 23 Feb 2015 02:50:37 -0500 Message-ID: <54EADBB6.4020005@freescale.com> Date: Mon, 23 Feb 2015 09:50:14 +0200 From: Purcareata Bogdan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Sebastian Andrzej Siewior , Paolo Bonzini , Alexander Graf , Bogdan Purcareata , , CC: , , , 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> <54E74D5E.1050209@linutronix.de> In-Reply-To: <54E74D5E.1050209@linutronix.de> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [192.88.166.1] X-ClientProxiedBy: DB4PR02CA0052.eurprd02.prod.outlook.com (10.242.174.180) To BY2PR03MB189.namprd03.prod.outlook.com (10.242.36.140) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=B43198@freescale.com; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB189; X-Bulk-Sender: Mark as legitimate X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(5005003);SRVR:BY2PR03MB189; X-Forefront-PRVS: 0496DF6962 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(6009001)(6049001)(479174004)(377454003)(24454002)(51704005)(189002)(199003)(80316001)(19580395003)(2950100001)(65956001)(54356999)(66066001)(65806001)(86362001)(105586002)(2201001)(97736003)(87976001)(93886004)(68736005)(59896002)(83506001)(92566002)(15975445007)(76176999)(64706001)(77096005)(42186005)(47776003)(46102003)(23746002)(106356001)(87266999)(33656002)(40100003)(64126003)(62966003)(77156002)(65816999)(50986999)(122386002)(36756003)(101416001)(50466002)(2101003)(42262002);DIR:OUT;SFP:1102;SCL:1;SRVR:BY2PR03MB189;H:[10.171.74.27];FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB189; X-OriginatorOrg: freescale.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Feb 2015 07:50:30.4027 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB189 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3008 Lines: 66 On 20.02.2015 17:06, Sebastian Andrzej Siewior wrote: > 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? The main reason for this patch was to enable KVM guests to run on RT hosts in certain scenarios, such as delivering external interrupts to the guest and the guest being SMP. The cyclictest measurements were just a "sanity check" to make sure the latencies don't get messed up too bad, albeit in a light scenario (guest with 1 VCPU), for a use case when the guest is not SMP and doesn't have any external interrupts delivered. This latter scenario works even without the kvm openpic being a raw_spinlock. Previous to this patch, KVM was indeed blowing up on guest_enter [1], and making the openpic lock a raw_spinlock fixes that, without causing too much cyclictest damage when the guest doesn't have many VCPUs. I had a discussion with Scott Wood a while ago regarding delivering external interrupts to the guest, and he mentioned that the correct solution was to rework the entire interrupt delivery mechanism into multiple lock domains, minimize the code on the EPR path and the locking involved. Until that can be achieved, converting the openpic lock to a raw_spinlock would be acceptable, as long as we keep the number of guest VCPUs small, so as to not cause big host latencies. [1] http://lxr.free-electrons.com/source/include/linux/kvm_host.h#L762 Best regards, Bogdan P. >> 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/