From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5C424C2D0E4 for ; Tue, 24 Nov 2020 08:24:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D61442073C for ; Tue, 24 Nov 2020 08:24:36 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=suse.com header.i=@suse.com header.b="SVplqW+T" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730431AbgKXIYg (ORCPT ); Tue, 24 Nov 2020 03:24:36 -0500 Received: from mx2.suse.de ([195.135.220.15]:33504 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726155AbgKXIYf (ORCPT ); Tue, 24 Nov 2020 03:24:35 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1606206274; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=5SRGiXX4dxU6UG326yCVJi+Xa49zYVgh4TutwaobuZ0=; b=SVplqW+TiU0cTnmG6Ntf657Uk5Sw6JBrX7TI6Qnjta5Zl4MT6U/FzDecJ+tR8HlC20JFOp Ik3JmkeUjR0fPPXlhJMxRtBgJEBDTd3X0J5gTKIX46SL+4MyHP7HOIzDadFfYQOD8MnvHF 1I3j+gP/duMmAofSJ1vP6Q4uw70+uYE= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 00B36AC48; Tue, 24 Nov 2020 08:24:33 +0000 (UTC) Date: Tue, 24 Nov 2020 09:24:33 +0100 From: Michal Hocko To: Pavel Tatashin Cc: Vlastimil Babka , linux-mm , Andrew Morton , LKML , David Hildenbrand , Oscar Salvador , Dan Williams , Sasha Levin , Tyler Hicks , Joonsoo Kim , sthemmin@microsoft.com, John Hubbard Subject: Re: Pinning ZONE_MOVABLE pages Message-ID: <20201124082433.GT27488@dhcp22.suse.cz> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon 23-11-20 11:31:59, Pavel Tatashin wrote: > > Makes sense, as this means no userspace change. > > > > > 2. Add an internal move_pages_zone() similar to move_pages() syscall > > > but instead of migrating to a different NUMA node, migrate pages from > > > ZONE_MOVABLE to another zone. > > > Call move_pages_zone() on demand prior to pinning pages from > > > vfio_pin_map_dma() for instance. > > > > As others already said, migrating away before the longterm pin should be > > the solution. IIRC it was one of the goals of long term pinning api > > proposed long time ago by Peter Ziljstra I think? The implementation > > that was merged relatively recently doesn't do that (yet?) for all > > movable pages, just CMA, but it could. > > From what I can tell, CMA is not solving exactly this problem. It > migrates pages from CMA before pinning, but it migrates them to > ZONE_MOVABLE. CMA suffers from a very similar problem. The existing solution is migrating out from the CMA region and it allows MOVABLE zones as well but that is merely an implementation detail and something that breaks movability on its own. So something to fix up, ideally for both cases. -- Michal Hocko SUSE Labs