From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0135.outbound.protection.outlook.com [65.55.169.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id BD7391A0C23 for ; Tue, 24 Feb 2015 10:27:46 +1100 (AEDT) Message-ID: <1424734051.4698.17.camel@freescale.com> Subject: Re: [PATCH 0/2] powerpc/kvm: Enable running guests on RT Linux From: Scott Wood To: Sebastian Andrzej Siewior Date: Mon, 23 Feb 2015 17:27:31 -0600 In-Reply-To: <54E74A8C.30802@linutronix.de> References: <1424251955-308-1-git-send-email-bogdan.purcareata@freescale.com> <54E73A6C.9080500@suse.de> <54E740E7.5090806@redhat.com> <54E74A8C.30802@linutronix.de> Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Cc: linux-rt-users@vger.kernel.org, Alexander Graf , linux-kernel@vger.kernel.org, Bogdan Purcareata , mihai.caraman@freescale.com, Paolo Bonzini , Thomas Gleixner , linuxppc-dev@lists.ozlabs.org List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Fri, 2015-02-20 at 15:54 +0100, Sebastian Andrzej Siewior wrote: > On 02/20/2015 03:12 PM, Paolo Bonzini wrote: > >> Thomas, what is the usual approach for patches like this? Do you take > >> them into your rt tree or should they get integrated to upstream? > > > > Patch 1 is definitely suitable for upstream, that's the reason why we > > have raw_spin_lock vs. raw_spin_unlock. > > raw_spin_lock were introduced in c2f21ce2e31286a0a32 ("locking: > Implement new raw_spinlock). They are used in context which runs with > IRQs off - especially on -RT. This includes usually interrupt > controllers and related core-code pieces. > > 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. This isn't a host PIC driver. It's guest PIC emulation, some of which is indeed not suitable for a rawlock (in particular, openpic_update_irq which loops on the number of vcpus, with a loop body that calls IRQ_check() which loops over all pending IRQs). The vcpu limits are a temporary bandaid to avoid the worst latencies, but I'm still skeptical about this being upstream material. -Scott From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Subject: Re: [PATCH 0/2] powerpc/kvm: Enable running guests on RT Linux Date: Mon, 23 Feb 2015 17:27:31 -0600 Message-ID: <1424734051.4698.17.camel@freescale.com> References: <1424251955-308-1-git-send-email-bogdan.purcareata@freescale.com> <54E73A6C.9080500@suse.de> <54E740E7.5090806@redhat.com> <54E74A8C.30802@linutronix.de> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Cc: linux-rt-users@vger.kernel.org, Alexander Graf , linux-kernel@vger.kernel.org, Bogdan Purcareata , mihai.caraman@freescale.com, Paolo Bonzini , Thomas Gleixner , linuxppc-dev@lists.ozlabs.org To: Sebastian Andrzej Siewior Return-path: In-Reply-To: <54E74A8C.30802@linutronix.de> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linuxppc-dev-bounces+glppe-linuxppc-embedded-2=m.gmane.org@lists.ozlabs.org Sender: "Linuxppc-dev" List-Id: linux-rt-users.vger.kernel.org T24gRnJpLCAyMDE1LTAyLTIwIGF0IDE1OjU0ICswMTAwLCBTZWJhc3RpYW4gQW5kcnplaiBTaWV3 aW9yIHdyb3RlOgo+IE9uIDAyLzIwLzIwMTUgMDM6MTIgUE0sIFBhb2xvIEJvbnppbmkgd3JvdGU6 Cj4gPj4gVGhvbWFzLCB3aGF0IGlzIHRoZSB1c3VhbCBhcHByb2FjaCBmb3IgcGF0Y2hlcyBsaWtl IHRoaXM/IERvIHlvdSB0YWtlCj4gPj4gdGhlbSBpbnRvIHlvdXIgcnQgdHJlZSBvciBzaG91bGQg dGhleSBnZXQgaW50ZWdyYXRlZCB0byB1cHN0cmVhbT8KPiA+IAo+ID4gUGF0Y2ggMSBpcyBkZWZp bml0ZWx5IHN1aXRhYmxlIGZvciB1cHN0cmVhbSwgdGhhdCdzIHRoZSByZWFzb24gd2h5IHdlCj4g PiBoYXZlIHJhd19zcGluX2xvY2sgdnMuIHJhd19zcGluX3VubG9jay4KPiAKPiByYXdfc3Bpbl9s b2NrIHdlcmUgaW50cm9kdWNlZCBpbiBjMmYyMWNlMmUzMTI4NmEwYTMyICgibG9ja2luZzoKPiBJ bXBsZW1lbnQgbmV3IHJhd19zcGlubG9jaykuIFRoZXkgYXJlIHVzZWQgaW4gY29udGV4dCB3aGlj aCBydW5zIHdpdGgKPiBJUlFzIG9mZiAtIGVzcGVjaWFsbHkgb24gLVJULiBUaGlzIGluY2x1ZGVz IHVzdWFsbHkgaW50ZXJydXB0Cj4gY29udHJvbGxlcnMgYW5kIHJlbGF0ZWQgY29yZS1jb2RlIHBp ZWNlcy4KPiAKPiBVc3VhbGx5IHlvdSBzZWUgInNjaGVkdWxpbmcgd2hpbGUgYXRvbWljIiBvbiAt UlQgYW5kIGNvbnZlcnQgdGhlbSB0bwo+IHJhdyBsb2NrcyBpZiBpdCBpcyBhcHByb3ByaWF0ZS4K PiAKPiBCb2dkYW4gd3JvdGUgaW4gMi8yIHRoYXQgaGUgbmVlZHMgdG8gbGltaXQgdGhlIG51bWJl ciBvZiBDUFVzIGluIG9kZXIKPiBub3QgY2F1c2UgYSBEb1MgYW5kIGxhcmdlIGxhdGVuY2llcyBp biB0aGUgaG9zdC4gSSBoYXZlbid0IHNlZW4gYW4KPiBhbnN3ZXIgdG8gbXkgd2h5IHF1ZXN0aW9u LiBCZWNhdXNlIGlmIHRoZSBjb252ZXJzYXRpb24gbGVhZHMgdG8KPiBsYXJnZSBsYXRlbmNpZXMg aW4gdGhlIGhvc3QgdGhlbiBpdCBkb2VzIG5vdCBsb29rIHJpZ2h0Lgo+IAo+IEVhY2ggaG9zdCBQ SUMgaGFzIGEgcmF3bG9jayBhbmQgZG9lcyBtb3N0bHkganVzdCBtYXNrL3VubWFzayBhbmQgdGhl Cj4gcmF3IGxvY2sgbWFrZXMgc3VyZSB0aGUgdmFsdWUgd3JpdHRlbiBpcyBub3QgbWl4ZWQgdXAg ZHVlIHRvCj4gcHJlZW1wdGlvbi4KPiBUaGlzIGhhcmRseSBpbmNyZWFzZSBsYXRlbmNpZXMgYmVj YXVzZSB0aGUgImxvY2tlZCIgcGF0aCBpcyB2ZXJ5IHNob3J0Lgo+IElmIHRoaXMgY29udmVyc2F0 aW9uIGxlYWRzIHRvIGhpZ2hlciBsYXRlbmNpZXMgdGhlbiB0aGUgbG9ja2VkIHBhdGggaXMKPiB0 b28gbG9uZyBhbmQgaGFyZGx5IHN1aXRhYmxlIHRvIGJlY29tZSBhIHJhd2xvY2suCgpUaGlzIGlz bid0IGEgaG9zdCBQSUMgZHJpdmVyLiAgSXQncyBndWVzdCBQSUMgZW11bGF0aW9uLCBzb21lIG9m IHdoaWNoCmlzIGluZGVlZCBub3Qgc3VpdGFibGUgZm9yIGEgcmF3bG9jayAoaW4gcGFydGljdWxh ciwgb3BlbnBpY191cGRhdGVfaXJxCndoaWNoIGxvb3BzIG9uIHRoZSBudW1iZXIgb2YgdmNwdXMs IHdpdGggYSBsb29wIGJvZHkgdGhhdCBjYWxscwpJUlFfY2hlY2soKSB3aGljaCBsb29wcyBvdmVy IGFsbCBwZW5kaW5nIElSUXMpLiAgVGhlIHZjcHUgbGltaXRzIGFyZSBhCnRlbXBvcmFyeSBiYW5k YWlkIHRvIGF2b2lkIHRoZSB3b3JzdCBsYXRlbmNpZXMsIGJ1dCBJJ20gc3RpbGwgc2tlcHRpY2Fs CmFib3V0IHRoaXMgYmVpbmcgdXBzdHJlYW0gbWF0ZXJpYWwuCgotU2NvdHQKCgpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpMaW51eHBwYy1kZXYgbWFpbGlu ZyBsaXN0CkxpbnV4cHBjLWRldkBsaXN0cy5vemxhYnMub3JnCmh0dHBzOi8vbGlzdHMub3psYWJz Lm9yZy9saXN0aW5mby9saW51eHBwYy1kZXY= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752157AbbBWX1n (ORCPT ); Mon, 23 Feb 2015 18:27:43 -0500 Received: from mail-bn1bon0137.outbound.protection.outlook.com ([157.56.111.137]:8659 "EHLO na01-bn1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751676AbbBWX1m (ORCPT ); Mon, 23 Feb 2015 18:27:42 -0500 Message-ID: <1424734051.4698.17.camel@freescale.com> Subject: Re: [PATCH 0/2] powerpc/kvm: Enable running guests on RT Linux From: Scott Wood To: Sebastian Andrzej Siewior CC: Paolo Bonzini , Alexander Graf , Bogdan Purcareata , , , , , "Thomas Gleixner" Date: Mon, 23 Feb 2015 17:27:31 -0600 In-Reply-To: <54E74A8C.30802@linutronix.de> References: <1424251955-308-1-git-send-email-bogdan.purcareata@freescale.com> <54E73A6C.9080500@suse.de> <54E740E7.5090806@redhat.com> <54E74A8C.30802@linutronix.de> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.7-0ubuntu1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Originating-IP: [2601:2:5800:3f7:12bf:48ff:fe84:c9a0] X-ClientProxiedBy: BY1PR00CA0013.namprd00.prod.outlook.com (25.160.102.23) To DM2PR0301MB0734.namprd03.prod.outlook.com (25.160.97.142) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=scottwood@freescale.com; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0734; 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:DM2PR0301MB0734; X-Forefront-PRVS: 0496DF6962 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(979002)(6009001)(479174004)(24454002)(199003)(51704005)(377424004)(377454003)(189002)(77156002)(33646002)(76176999)(36756003)(110136001)(50986999)(87976001)(46102003)(50226001)(62966003)(42186005)(101416001)(106356001)(50466002)(64706001)(47776003)(93886004)(103116003)(92566002)(575784001)(86362001)(105586002)(5820100001)(122386002)(2950100001)(97736003)(40100003)(23676002)(68736005)(99106002)(3826002)(969003)(989001)(999001)(1009001)(1019001);DIR:OUT;SFP:1102;SCL:1;SRVR:DM2PR0301MB0734;H:[IPv6:2601:2:5800:3f7:12bf:48ff:fe84:c9a0];FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0734; X-OriginatorOrg: freescale.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Feb 2015 23:27:38.8472 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0734 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2015-02-20 at 15:54 +0100, Sebastian Andrzej Siewior wrote: > On 02/20/2015 03:12 PM, Paolo Bonzini wrote: > >> Thomas, what is the usual approach for patches like this? Do you take > >> them into your rt tree or should they get integrated to upstream? > > > > Patch 1 is definitely suitable for upstream, that's the reason why we > > have raw_spin_lock vs. raw_spin_unlock. > > raw_spin_lock were introduced in c2f21ce2e31286a0a32 ("locking: > Implement new raw_spinlock). They are used in context which runs with > IRQs off - especially on -RT. This includes usually interrupt > controllers and related core-code pieces. > > 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. This isn't a host PIC driver. It's guest PIC emulation, some of which is indeed not suitable for a rawlock (in particular, openpic_update_irq which loops on the number of vcpus, with a loop body that calls IRQ_check() which loops over all pending IRQs). The vcpu limits are a temporary bandaid to avoid the worst latencies, but I'm still skeptical about this being upstream material. -Scott