Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp187885imj; Thu, 14 Feb 2019 18:15:55 -0800 (PST) X-Google-Smtp-Source: AHgI3IYqIMY77D+2j82jDi8UESqGtnKF4bLNJfGG+DPriXjcY99NJUat8AaQGP99LGFCJvDqAUwM X-Received: by 2002:a17:902:f08b:: with SMTP id go11mr7544507plb.115.1550196954974; Thu, 14 Feb 2019 18:15:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550196954; cv=none; d=google.com; s=arc-20160816; b=Tf9gdC20i0sbBNIjL6e6jpSWe6ks6bwY+vpZ7+QaZdlPOSuMddzrTzdbfosFO3N0bQ QmUMfIbJq9hyLdV6u1wsYBAHe7ZbbIaH58YrXoW4zRY1VNjb8khStU0nFJhdkHq8nAFk fvBOox+j8i829sg6019tILwUs6GT+y3kgaYVd1XvSLX/gSVV8mIetvy6iVwEFME1mKIo EJopbiMPqMex3Ai40gpweoHOcC5872ejMMKa7gWQ74+6glExoqPzOO18JUk8Hx9Xcpgf ZHOGSgx+pKLC7gvKqIakU8/Oqn4IFxzrqU1O96YfTYbXthBcLN8mwPcEVfUGgCkvaa8z zUpg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=0Hts8HKfoq6xzawpRQkWO0Qyk4NLI1ZN8C3xnvZokNc=; b=avj2Rn4YluA4icUwURsGifPNW6sVydK4OxkL1lsPvXrUnsTWhaRC5W/PIpNI50dqiN NLUmRtsoKmKGQEnhL0os9LFiVlFm4yUuu00TjtqBp/ZqxRFt40bNBWDC8BEdct/TSvSB zmVmzmiTkIUi1u1k4jiE9vcg5j7a8WC3R+I4+5Wi0zvHGLieDail1sZpRVqNdz4Enlhc H3OLFMWfT9o1SFN16MtLcKs83gGNvrTSUctRX7QABedGkkbvA30DqN6hlqszZ6YaRx7Q 4ZSVDEgdL8v3wg9gTvCWEXXmNXYweQCoj+ytbQUX0mMGWiLBWYOJh1a3Oo6sViocuW3V 9REw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q16si4038417pgh.185.2019.02.14.18.15.39; Thu, 14 Feb 2019 18:15:54 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2437811AbfBNVWm (ORCPT + 99 others); Thu, 14 Feb 2019 16:22:42 -0500 Received: from mx1.redhat.com ([209.132.183.28]:43280 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387702AbfBNVWm (ORCPT ); Thu, 14 Feb 2019 16:22:42 -0500 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0B5DF42BDA; Thu, 14 Feb 2019 21:22:41 +0000 (UTC) Received: from sky.random (ovpn-120-178.rdu2.redhat.com [10.10.120.178]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 38425611B3; Thu, 14 Feb 2019 21:22:37 +0000 (UTC) Date: Thu, 14 Feb 2019 16:22:36 -0500 From: Andrea Arcangeli To: Andrew Morton Cc: Michal Hocko , "Huang, Ying" , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Hugh Dickins , "Paul E . McKenney" , Minchan Kim , Johannes Weiner , Tim Chen , Mel Gorman , =?iso-8859-1?B?Suly9G1l?= Glisse , David Rientjes , Rik van Riel , Jan Kara , Dave Jiang , Daniel Jordan , Andrea Parri Subject: Re: [PATCH -mm -V7] mm, swap: fix race between swapoff and some swap operations Message-ID: <20190214212236.GA10698@redhat.com> References: <20190211083846.18888-1-ying.huang@intel.com> <20190214143318.GJ4525@dhcp22.suse.cz> <20190214123002.b921b680fea07bf5f798df79@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190214123002.b921b680fea07bf5f798df79@linux-foundation.org> User-Agent: Mutt/1.11.3 (2019-02-01) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Thu, 14 Feb 2019 21:22:42 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, On Thu, Feb 14, 2019 at 12:30:02PM -0800, Andrew Morton wrote: > This was discussed to death and I think the changelog explains the > conclusions adequately. swapoff is super-rare so a stop_machine() in > that path is appropriate if its use permits more efficiency in the > regular swap code paths. The problem is precisely that the way the stop_machine callback is implemented right now (a dummy noop), makes the stop_machine() solution fully equivalent to RCU from the fast path point of view. It does not permit more efficiency in the fast path which is all we care about. For the slow path point of view the only difference is possibly that stop_machine will reach the quiescent state faster (i.e. swapoff may return a few dozen milliseconds faster), but nobody cares about the latency of swapoff and it's actually nicer if swapoff doesn't stop all CPUs on large systems and it uses less CPU overall. This is why I suggested if we keep using stop_machine() we should not use a dummy function whose only purpose is to reach a queiscent state (which is something that is more efficiently achieved with the syncronize_rcu/sched/kernel RCU API of the day) but we should instead try to leverage the UP-like serialization to remove more spinlocks from the fast path and convert them to preempt_disable(). However the current dummy callback cannot achieve that higher efficiency in the fast paths, the code would need to be reshuffled to try to remove at least the swap_lock. If no spinlock is converted to preempt_disable() RCU I don't see the point of stop_machine(). On a side note, the cmpxchge machinery I posted to run the function simultaneously on all CPUs I think may actually be superflous if using cpus=NULL like Hing suggested. Implementation details aside, still the idea of stop_machine would be to do those p->swap_map = NULL and everything protected by the swap_lock, should be executed inside the callback that runs like in a UP system to speedup the fast path further. Thanks, Andrea