From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S937085AbcKKUzD (ORCPT ); Fri, 11 Nov 2016 15:55:03 -0500 Received: from mx1.redhat.com ([209.132.183.28]:38250 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S936495AbcKKUzA (ORCPT ); Fri, 11 Nov 2016 15:55:00 -0500 Date: Fri, 11 Nov 2016 15:54:56 -0500 From: Luiz Capitulino To: Thomas Gleixner Cc: Chris Metcalf , Gilad Ben Yossef , Steven Rostedt , Ingo Molnar , Peter Zijlstra , Andrew Morton , Rik van Riel , Tejun Heo , Frederic Weisbecker , "Paul E. McKenney" , Christoph Lameter , Viresh Kumar , Catalin Marinas , Will Deacon , Andy Lutomirski , Daniel Lezcano , Francis Giraldeau , Andi Kleen , Arnd Bergmann , linux-kernel@vger.kernel.org Subject: Re: task isolation discussion at Linux Plumbers Message-ID: <20161111155456.0b8b8589@redhat.com> In-Reply-To: References: <1471382376-5443-1-git-send-email-cmetcalf@mellanox.com> <1605b087-2b3b-77c1-01ac-084e378f5f28@mellanox.com> Organization: Red Hat MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Fri, 11 Nov 2016 20:55:00 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 7 Nov 2016 17:55:47 +0100 (CET) Thomas Gleixner wrote: > On Sat, 5 Nov 2016, Chris Metcalf wrote: > > == Remote statistics == > > > > We discussed the possibility of remote statistics gathering, i.e. load > > average etc. The idea would be that we could have housekeeping > > core(s) periodically iterate over the nohz cores to load their rq > > remotely and do update_current etc. Presumably it should be possible > > for a single housekeeping core to handle doing this for all the > > nohz_full cores, as we only need to do it quite infrequently. > > > > Thomas suggested that this might be the last remaining thing that > > needed to be done to allow disabling the current behavior of falling > > back to a 1 Hz clock in nohz_full. > > > > I believe Thomas said he had a patch to do this already. > > No, Riek was working on that. Rik series made it possible to have remote tick sampling. That is, calling account_process_tick(cpu) from a housekeeping CPU, so that tick accounting is done for a remote "cpu". The series was intended to improve overhead on nohz_full CPUs. However, to get rid of the 1Hz tick, we need to do the same thing for scheduler_tick(). I'm not sure if this has been attempted yet, and if it's at all possible. > > == Remote LRU cache drain == > > > > One of the issues with task isolation currently is that the LRU cache > > drain must be done prior to entering userspace, but it requires > > interrupts enabled and thus can't be done atomically. My previous > > patch series have handled this by checking with interrupts disabled, > > but then looping around with interrupts enabled to try to drain the > > LRU pagevecs. Experimentally this works, but it's not provable that > > it terminates, which is worrisome. Andy suggested adding a percpu > > flag to disable creation of deferred work like LRU cache pages. > > > > Thomas suggested using an RT "local lock" to guard the LRU cache > > flush; he is planning on bringing the concept to mainline in any case. > > However, after some discussion we converged on simply using a spinlock > > to guard the appropriate resources. As a result, the > > lru_add_drain_all() code that currently queues work on each remote cpu > > to drain it, can instead simply acquire the lock and drain it remotely. > > This means that a task isolation task no longer needs to worry about > > being interrupted by SMP function call IPIs, so we don't have to deal > > with this in the task isolation framework any more. > > > > I don't recall anyone else volunteering to tackle this, so I will plan > > to look at it. The patch to do that should be orthogonal to the > > revised task isolation patch series. > > I offered to clean up the patch from RT. I'll do that in the next days. Yes, the RT kernel got a patch that fixes this. I wonder if the same idea could work for vm_stat (that is, gathering those stats from housekeeping CPUs vs. having to queue deferrable work to do it).