Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751732AbdIQRER (ORCPT ); Sun, 17 Sep 2017 13:04:17 -0400 Received: from mail-wr0-f172.google.com ([209.85.128.172]:51664 "EHLO mail-wr0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751410AbdIQREQ (ORCPT ); Sun, 17 Sep 2017 13:04:16 -0400 X-Google-Smtp-Source: ADKCNb5fn2oxhF+2FDPvK+kNoeDhGm5SQMHrXbX4On/yTFeDpFDc+LfbQ2WtF64EdD702QuYBp1tzg== Date: Sun, 17 Sep 2017 19:04:11 +0200 From: Ingo Molnar To: Andy Lutomirski Cc: Borislav Petkov , Peter Zijlstra , Linus Torvalds , Markus Trippelsdorf , Thomas Gleixner , LKML , Ingo Molnar , Tom Lendacky , Rik van Riel Subject: Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf Message-ID: <20170917170411.6lvwixxtmx3mbyrd@gmail.com> References: <20170909172352.GA290@x4> <20170909173633.4ttfk7maooxkcwum@pd.tnic> <20170909181445.GA281@x4> <20170909182952.itqad4ryngjwrgqf@pd.tnic> <20170909190948.xydyega7i2rjnlqt@pd.tnic> <20170909193750.l5o5xtquogmscmom@pd.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 987 Lines: 24 * Andy Lutomirski wrote: > PeterZ and Ingo, would you be okay with adding a define so arches can > opt out of the task_struct::active_mm field entirely? That is, with > the option set, task_struct wouldn't have an active_mm field, the core > wouldn't call mmgrab and mmdrop, and the arch would be responsible for > that bookkeeping instead? x86, and presumably all arches without > cross-core invalidation, would probably prefer to just shoot down the > old mm entirely in __mmput() rather than trying to figure out when do > finish freeing old mms. After all, exit_mmap() is going to send an > IPI regardless, so I see no reason to have the scheduler core pin an > old dead mm just because some random kernel thread's active_mm field > points to it. > > IOW, if I'm going to reintroduce something like what the old lazy mode > did on x86, I'd rather do it right. How realistic would it be to get rid of ::active_mm on all architectures at once? Thanks, Ingo