From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932388AbdIYC3D (ORCPT ); Sun, 24 Sep 2017 22:29:03 -0400 Received: from mx1.redhat.com ([209.132.183.28]:50102 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753343AbdIYC3A (ORCPT ); Sun, 24 Sep 2017 22:29:00 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com AF5F5883B8 Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=mtosatti@redhat.com Date: Sun, 24 Sep 2017 23:22:38 -0300 From: Marcelo Tosatti To: Peter Zijlstra Cc: Konrad Rzeszutek Wilk , mingo@redhat.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Thomas Gleixner Subject: Re: [patch 3/3] x86: kvm guest side support for KVM_HC_RT_PRIO hypercall\ Message-ID: <20170925022238.GB5140@amt.cnet> References: <20170921113835.031375194@redhat.com> <20170921114039.466130276@redhat.com> <20170921133653.GO26248@char.us.oracle.com> <20170921140628.zliqlz7mrlqs5pzz@hirez.programming.kicks-ass.net> <20170922011039.GB20133@amt.cnet> <20170922100004.ydmaxvgpc2zx7j25@hirez.programming.kicks-ass.net> <20170922121640.GA29589@amt.cnet> <20170922123107.fjh2yfwnej73trim@hirez.programming.kicks-ass.net> <20170922124005.GA30393@amt.cnet> <20170922130141.tz6f4gktihmbhqli@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170922130141.tz6f4gktihmbhqli@hirez.programming.kicks-ass.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Mon, 25 Sep 2017 02:29:00 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 22, 2017 at 03:01:41PM +0200, Peter Zijlstra wrote: > On Fri, Sep 22, 2017 at 09:40:05AM -0300, Marcelo Tosatti wrote: > > > Are you arguing its invalid for the following application to execute on > > housekeeping vcpu of a realtime system: > > > > void main(void) > > { > > > > submit_IO(); > > do { > > computation(); > > } while (!interrupted()); > > } > > > > Really? > > No. Nobody cares about random crap tasks. Nobody has control over all code that runs in userspace Peter. And not supporting a valid sequence of steps because its "crap" (whatever your definition of crap is) makes no sense. It might be that someone decides to do the above (i really can't see any actual reasoning i can follow and agree on your "its crap" argument), this truly seems valid to me. So lets follow the reasoning steps: 1) "NACK, because you didnt understand the problem". OK thats an invalid NACK, you did understand the problem later and now your argument is the following. 2) "NACK, because all VCPUs should be SCHED_FIFO all the time". But the existence of this code path from userspace: submit_IO(); do { computation(); } while (!interrupted()); Its a supported code sequence, and works fine in a non-RT environment. Therefore it should work on an -RT environment. Think of any two applications, such as an IO application and a CPU bound application. The IO application will be severely impacted, or never execute, in such scenario. Is that combination of tasks "random crap tasks" ? (No, its not, which makes me think you're just NACKing without giving enough thought to the problem). So please give me some logical reasoning for the NACK (people can live with it, but it has to be good enough to justify the decreasing packing of guests in pCPUs): 1) "Voodoo programming" (its hard for me to parse what you mean with that... do you mean you foresee this style of priority boosting causing problems in the future? Can you give an example?). Is there fundamentally wrong about priority boosting in spinlock sections, or this particular style of priority boosting is wrong? 2) "Pollution of the kernel code path". That makes sense to me, if thats whats your concerned about. 3) "Reduction of spinlock performance". Its true, but for NFV workloads people don't care about. 4) "All vcpus should be SCHED_FIFO all the time". OK, why is that? What dictates that to be true? What the patch does is the following: It reduces the window where SCHED_FIFO is applied vcpu0 to those were a spinlock is shared between -RT vcpus and vcpu0 (why: because otherwise, when the emulator thread is sharing a pCPU with vcpu0, its unable to generate interrupts vcpu0). And its being rejected because: Please fill in.