From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751548AbbBWH33 (ORCPT ); Mon, 23 Feb 2015 02:29:29 -0500 Received: from mail-bl2on0117.outbound.protection.outlook.com ([65.55.169.117]:42466 "EHLO na01-bl2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750818AbbBWH32 (ORCPT ); Mon, 23 Feb 2015 02:29:28 -0500 Message-ID: <54EAD6C2.3080601@freescale.com> Date: Mon, 23 Feb 2015 09:29:06 +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> In-Reply-To: <54E74A8C.30802@linutronix.de> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [192.88.166.1] X-ClientProxiedBy: DB3PR05CA0016.eurprd05.prod.outlook.com (25.160.41.144) To BN1PR03MB185.namprd03.prod.outlook.com (10.255.200.139) 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:BN1PR03MB185; 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:BN1PR03MB185; X-Forefront-PRVS: 0496DF6962 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(6009001)(6049001)(24454002)(189002)(377454003)(479174004)(51704005)(199003)(76176999)(66066001)(47776003)(65816999)(87976001)(64706001)(46102003)(83506001)(65956001)(65806001)(2201001)(64126003)(106356001)(92566002)(50986999)(80316001)(97736003)(122386002)(87266999)(54356999)(105586002)(50466002)(40100003)(77096005)(101416001)(59896002)(2950100001)(62966003)(77156002)(86362001)(575784001)(23746002)(93886004)(36756003)(42186005)(33656002)(68736005)(42262002)(2101003);DIR:OUT;SFP:1102;SCL:1;SRVR:BN1PR03MB185;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:BN1PR03MB185; X-OriginatorOrg: freescale.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Feb 2015 07:29:22.3525 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR03MB185 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 20.02.2015 16:54, 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. What I did notice were bad cyclictest results, when run in a guest with 24 VCPUs. There were 24 netperf flows running in the guest. The max cyclictest latencies got up to 15ms in the guest, however I haven't captured any host side information related to preemptirqs off statistics. What I was planning to do in the past days was to rerun the test and come up with the host preemptirqs off disabled statistics (mainly the max latency), so I could have a more reliable argument. I haven't had the time nor the setup to do that yet, and will come back with this as soon as I have them available. > 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. From my understanding, the kvm openpic emulation code does more than just that - it requires to be atomic with interrupt delivery. This might mean the bad cyclictest max latencies visible from the guest side (15ms), may also have a correspondent to how much time that raw spinlock is taken, leading to an unresponsive host. Best regards, Bogdan P. >> Paolo >> > > Sebastian >