From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934255AbdEZTKV (ORCPT ); Fri, 26 May 2017 15:10:21 -0400 Received: from mx1.redhat.com ([209.132.183.28]:56236 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932288AbdEZTKQ (ORCPT ); Fri, 26 May 2017 15:10:16 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 127B680499 Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=mtosatti@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 127B680499 Date: Fri, 26 May 2017 16:09:29 -0300 From: Marcelo Tosatti To: Christoph Lameter Cc: Luiz Capitulino , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Rik van Riel , Linux RT Users , cmetcalf@mellanox.com Subject: Re: [patch 2/2] MM: allow per-cpu vmstat_threshold and vmstat_worker configuration Message-ID: <20170526190926.GA8974@amt.cnet> References: <20170512161915.GA4185@amt.cnet> <20170515191531.GA31483@amt.cnet> <20170519143407.GA19282@amt.cnet> <20170519134934.0c298882@redhat.com> <20170525193508.GA30252@amt.cnet> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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.28]); Fri, 26 May 2017 19:10:06 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 25, 2017 at 10:24:46PM -0500, Christoph Lameter wrote: > On Thu, 25 May 2017, Marcelo Tosatti wrote: > > > Argument? We're showing you the data that this is causing a latency > > problem for us. > > Sorry I am not sure where the data shows a latency problem. There are > interrupts and scheduler ticks. But what does this have to do with vmstat? > > Show me your dpdk code running and trace the tick on / off events as well > as the vmstat invocations. Also show all system calls occurring on the cpu > that runs dpdk. That is necessary to see what triggers vmstat and how the > system reacts to the changes to the differentials. Sure, i can get that to you. The question remains: Are you arguing its not valid for a realtime application to use any system call which changes a vmstat counter? Because if they are allowed, then its obvious something like this is needed. > Then please rerun the test by setting the vmstat_interval to 60. > > Do another run with your modifications and show the difference. Will do so. > > > Something that crossed my mind was to add a new tunable to set > > > the vmstat_interval for each CPU, this way we could essentially > > > disable it to the CPUs where DPDK is running. What's the implications > > > of doing this besides not getting up to date stats in /proc/vmstat > > > (which I still have to confirm would be OK)? Can this break anything > > > in the kernel for example? > > > > Well, you get incorrect statistics. > > The statistics are never completely accurate. You will get less accurate > statistics but they will be correct. The differentials may not be > reflected in the counts shown via /proc but there is a cap on how > inaccurate those can becore.