From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756908AbdEKPfU (ORCPT ); Thu, 11 May 2017 11:35:20 -0400 Received: from mx1.redhat.com ([209.132.183.28]:27323 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754545AbdEKPd7 (ORCPT ); Thu, 11 May 2017 11:33:59 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com B294540F33 Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=mtosatti@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com B294540F33 Date: Thu, 11 May 2017 12:33:29 -0300 From: Marcelo Tosatti To: Rik van Riel Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, Luiz Capitulino , Linux RT Users Subject: Re: [patch 3/3] MM: allow per-cpu vmstat_worker configuration Message-ID: <20170511153326.GB2308@amt.cnet> References: <20170503184007.174707977@redhat.com> <20170503184039.901336380@redhat.com> <1494430466.29205.17.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1494430466.29205.17.camel@redhat.com> 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.30]); Thu, 11 May 2017 15:33:53 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 10, 2017 at 11:34:26AM -0400, Rik van Riel wrote: > On Wed, 2017-05-03 at 15:40 -0300, Marcelo Tosatti wrote: > > Following the reasoning on the last patch in the series, > > this patch allows configuration of the per-CPU vmstat worker: > > it allows the user to disable the per-CPU vmstat worker. > > > > Signed-off-by: Marcelo Tosatti > > Is there ever a case where you would want to configure > this separately from the vmstat_threshold parameter? > > What use cases are you trying to address? If you have a case where the performance decrease due to lack of vmstat collection aggretation (vmstat_threshold=1) is significant, so you increase vmstat_threshold on these CPUs to, say, 10 (and is willing to accept the cost of outdated vmstatistics by 10). This is the case that i imagined when separating the options in two (with the idea to have policy in userspace, not in the kernel). Do you think such case is not realistic? (Or that there are other problems by having vmstat_threshold > 1 and vmstat_worker=0).