From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 1C5E3C433F5 for ; Thu, 16 Dec 2021 09:20:53 +0000 (UTC) Received: from localhost ([::1]:53786 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mxmwW-0006jl-5B for qemu-devel@archiver.kernel.org; Thu, 16 Dec 2021 04:20:52 -0500 Received: from eggs.gnu.org ([209.51.188.92]:44572) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mxmt2-0001hl-18 for qemu-devel@nongnu.org; Thu, 16 Dec 2021 04:17:16 -0500 Received: from prt-mail.chinatelecom.cn ([42.123.76.221]:37155 helo=chinatelecom.cn) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mxmsz-0001tZ-09 for qemu-devel@nongnu.org; Thu, 16 Dec 2021 04:17:15 -0500 HMM_SOURCE_IP: 172.18.0.188:59972.1360648331 HMM_ATTACHE_NUM: 0000 HMM_SOURCE_TYPE: SMTP Received: from clientip-182.150.57.243 (unknown [172.18.0.188]) by chinatelecom.cn (HERMES) with SMTP id EF0142800B6; Thu, 16 Dec 2021 17:16:52 +0800 (CST) X-189-SAVE-TO-SEND: huangy81@chinatelecom.cn Received: from ([172.18.0.188]) by app0023 with ESMTP id 1ed9122d40414286ac1bc2318c40b003 for peterx@redhat.com; Thu, 16 Dec 2021 17:17:00 CST X-Transaction-ID: 1ed9122d40414286ac1bc2318c40b003 X-Real-From: huangy81@chinatelecom.cn X-Receive-IP: 172.18.0.188 X-MEDUSA-Status: 0 Message-ID: Date: Thu, 16 Dec 2021 17:16:55 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Subject: Re: [PATCH v10 3/3] cpus-common: implement dirty page limit on virtual CPU To: Peter Xu , Markus Armbruster References: <874k7anwtc.fsf@dusky.pond.sub.org> <4397f17c-4431-8480-127b-4228271523c8@chinatelecom.cn> <87y24m2df7.fsf@dusky.pond.sub.org> From: Hyman Huang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=42.123.76.221; envelope-from=huangy81@chinatelecom.cn; helo=chinatelecom.cn X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, NICE_REPLY_A=-0.034, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Eduardo Habkost , David Hildenbrand , Juan Quintela , Richard Henderson , qemu-devel , "Dr. David Alan Gilbert" , Paolo Bonzini , =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" 在 2021/12/16 14:22, Peter Xu 写道: > On Wed, Dec 15, 2021 at 02:41:32PM +0100, Markus Armbruster wrote: >> Peter Xu writes: >> >>> On Wed, Dec 15, 2021 at 03:56:55PM +0800, Hyman Huang wrote: >>>>>> +{ 'command': 'vcpu-dirty-limit', >>>>>> + 'data': { 'enable': 'bool', >>>>>> + '*cpu-index': 'uint64', >>>>>> + '*dirty-rate': 'uint64'} } >>>>> >>>>> Drop @enable, please. >>>>> >>>>> If @dirty-rate is present, set the limit to its value. >>>>> >>>>> If it's absent, cancel the limit. >>>>> >>>> Ok. Indeed, this is the simplest style. :) >>>> >>>> So the final qmp format should be like: >>>> >>>> case 1: setup vcpu 0 dirty page limit 100MB/s >>>> vcpu-dirty-limit cpu-index=0 dirty-rate=100MB/s >>>> >>>> case 2: cancle vcpu 0 dirty page limit >>>> vcpu-dirty-limit cpu-index=0 >>> >>> I actually agree with what you said... for human beings no one will read it as >>> "disable vcpu throttling", instead people could consider it enables vcpu >>> throttle with a default dirty rate from a gut feeling. >>> >>> I think what Markus suggested is the simplest solution for computers, but it >>> can confuse human beings. So it turns out to be a general question to QMP >>> scheme design: should we always assume QMP client to be a piece of software, or >>> should we still consider the feeling of human beings operating on QMP >>> interfaces using qmp-shell. >>> >>> IMHO we should still consider the latter, if we don't lose much, anyway. But I >>> don't have a strong opinion. >> >> If you want a more explicit interface, then I'd recommend to go right >> back to v7: >> >> {"execute": "set-vcpu-dirty-limit", >> "arguments": {"cpu-index": 0, "dirtyrate": 200}} >> >> {"execute": "cancel-vcpu-dirty-limit", >> "arguments": {"cpu-index": 0}} >> >> Bonus: it already has my Acked-by. > > Fair enough. :) That looks good to me too. > > Yong, please hold-off a bit on reposting (if there's a plan) - I'll read the > other parts soon.. > Ok, i'm not going to repost the next version untill the consensus is achieved. So the final format of qmp we conclude are: case 1: setup vcpu 0 dirty page limit 100MB/s set-vcpu-dirty-limit cpu-index=0 dirty-rate=100 case 2: setup all vcpu dirty page limit 100MB/s set-vcpu-dirty-limit dirty-rate=100 case 3: cancel vcpu 0 dirty page limit cancel-vcpu-dirty-limit cpu-index=0 case 4: cancel all vcpu dirty page limit cancel-vcpu-dirty-limit case 5: query limit infomatioin of all vcpu enabled query-vcpu-dirty-limit And the corresponding hmp format keep the same style: Is there any advice? :) > Thanks, > -- Best regard Hyman Huang(黄勇)