From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752953AbbC3POt (ORCPT ); Mon, 30 Mar 2015 11:14:49 -0400 Received: from casper.infradead.org ([85.118.1.10]:34517 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752472AbbC3POq (ORCPT ); Mon, 30 Mar 2015 11:14:46 -0400 Date: Mon, 30 Mar 2015 17:14:31 +0200 From: Peter Zijlstra To: Michal Hocko Cc: Viresh Kumar , Andrew Morton , hannes@cmpxchg.org, Christoph Lameter , Linaro Kernel Mailman List , Linux Kernel Mailing List , vinmenon@codeaurora.org, shashim@codeaurora.org, mgorman@suse.de, dave@stgolabs.net, koct9i@gmail.com, Linux Memory Management List , Suresh Siddha , Thomas Gleixner Subject: Re: [RFC] vmstat: Avoid waking up idle-cpu to service shepherd work Message-ID: <20150330151431.GA23123@twins.programming.kicks-ass.net> References: <359c926bc85cdf79650e39f2344c2083002545bb.1427347966.git.viresh.kumar@linaro.org> <20150326131822.fce6609efdd85b89ceb3f61c@linux-foundation.org> <20150327091613.GE27490@worktop.programming.kicks-ass.net> <20150327093023.GA32047@worktop.ger.corp.intel.com> <20150328095322.GH27490@worktop.programming.kicks-ass.net> <20150330150818.GE3909@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150330150818.GE3909@dhcp22.suse.cz> User-Agent: Mutt/1.5.21 (2012-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 30, 2015 at 05:08:18PM +0200, Michal Hocko wrote: > On Sat 28-03-15 10:53:22, Peter Zijlstra wrote: > [...] > > Alternatively the thing hocko suggests is an utter fail too. You cannot > > stuff that into hardirq context, that's insane. > > I guess you are referring to > http://article.gmane.org/gmane.linux.kernel.mm/127569, right? > > Why cannot we do something like refresh_cpu_vm_stats from the IRQ > context? Especially the first zone stat part. Big machines have big zone counts. There are machines with >200 nodes. Although with the current trend of bigger nodes, the number of nodes seems to come down as well. Still. > The per-cpu pagesets is > more costly and it would need a special treatment, alright. A simple > way would be to splice the lists from the per-cpu context and then free > those pages from the kthread context. > > I am still wondering why those two things were squashed into a single > place. Why kswapd is not doing the pcp cleanup? Probably because they could be. The problem with kswapd is that its per node, not per cpu.