From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id DACDFA034F; Sat, 2 Nov 2019 00:00:08 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 17C051E871; Sat, 2 Nov 2019 00:00:08 +0100 (CET) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) by dpdk.org (Postfix) with ESMTP id 3ED091E868 for ; Sat, 2 Nov 2019 00:00:06 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 1A70153D; Fri, 1 Nov 2019 19:00:05 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Fri, 01 Nov 2019 19:00:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=KMl4sIzkOG22yoscYVEMwWKVCm6Ocb697orb2bkIxzg=; b=aXkebZAX7saq Yi6OIr83OBSV7KqboOL8X5Ls9b/EXisfPu/dTYgC1LvTlaj19084LcBjnEujXTtJ f76VwZe2mZC5F9bjduhspFBhJoPOMXfQkU6935rBkcTwUdGFkT8wABBpD7g3BBhN yZuLP7MG7MAnbV/tJU4JHNJgezWaEIw= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=KMl4sIzkOG22yoscYVEMwWKVCm6Ocb697orb2bkIx zg=; b=wDjBbfrAICDClv8Z8czQqO+lbHSHiErUXjjKCxIp6bFNhAXMspPS+svhv xuVMYpR6odI635YA3dC0WIO7OdBpWlEAQhXOBWjiBQaYN5FpvMO3W4/Z+7gpVFvK 9mT59HUkQaYYDUfhODKKX1MWW/186y65hd+ROoseNZPFo6g5ZBqhbrX02FczANPJ POnx+e29UY/F0YbcT2OP7GYaQiNbE+kn7qBxnpuGsaJPEFi9To9QB6SozZwZglAf P0zPZIB9cLW87/QlwwmZbCOeowpku2i3mqG/yWkPcP1xlV6Y1tiXkY7CPPtFSv6N ykaVoSDilLA3+wEslR6ftmu9L8pIw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedruddtkedgtdefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecukf hppeelfedriedrudegledruddugeenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhm rghssehmohhnjhgrlhhonhdrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from xps.localnet (114.149.6.93.rev.sfr.net [93.6.149.114]) by mail.messagingengine.com (Postfix) with ESMTPA id D7B288006A; Fri, 1 Nov 2019 19:00:02 -0400 (EDT) From: Thomas Monjalon To: "Hunt, David" Cc: "Burakov, Anatoly" , dev@dpdk.org Date: Sat, 02 Nov 2019 00:00:01 +0100 Message-ID: <2092105.X2fBbGLaSI@xps> In-Reply-To: <0c0b07e4-ef84-056f-bffa-06a402fa99f6@intel.com> References: <20190724131803.30066-1-david.hunt@intel.com> <1655765.anAStuQWUM@xps> <0c0b07e4-ef84-056f-bffa-06a402fa99f6@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v1] examples/power: fix oob frequency oscillations X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 29/10/2019 15:05, Hunt, David: > On 27/10/2019 18:35, Thomas Monjalon wrote: > > 06/08/2019 13:18, Thomas Monjalon: > >> 26/07/2019 12:15, Burakov, Anatoly: > >>> So it's biased towards scaling up quickly, but it's doing that over a > >>> period. Please correct me if i'm wrong as i'm not really familiar with > >>> this codebase, but, assuming the window size is long enough, you could > >>> be missing opportunities to scale down? For example, if you get a short > >>> burst of 1's followed by a long burst of zeroes, you're not scaling down > >>> until you go through the entire buffer and overwrite all of the values. > >>> I guess that's the point of oscillation prevention, but maybe you could > >>> improve the "scale-up" part by only checking a few recent values, rather > >>> than the entire buffer? > >> This patch is deferred to 19.11. > > Any news for this patch? > > > The algorithm was intended to be biased (strongly) towards the scale-up, > for performance reasons. If there is a single "scale-up" in the entire > array, then we stay up until the entire array agrees that we can scale > down. If the user wants to relax this, then simply reduce the size of > the array, which will have the same affect. But I had tested it with an > array size of 32, and that gave the best results for my use cases. I'm not sure to understand. The patch is rejected?