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=-2.5 required=3.0 tests=MAILING_LIST_MULTI,SPF_PASS, USER_AGENT_MUTT autolearn=ham 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 AD1A7C43142 for ; Tue, 26 Jun 2018 13:48:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 708B326B96 for ; Tue, 26 Jun 2018 13:48:03 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 708B326B96 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935818AbeFZNsB (ORCPT ); Tue, 26 Jun 2018 09:48:01 -0400 Received: from mx2.suse.de ([195.135.220.15]:43949 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933522AbeFZNsA (ORCPT ); Tue, 26 Jun 2018 09:48:00 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (charybdis-ext-too.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 53ECCAC85; Tue, 26 Jun 2018 13:47:58 +0000 (UTC) Date: Tue, 26 Jun 2018 15:47:57 +0200 From: Michal Hocko To: Dan Williams Cc: John Hubbard , Christoph Hellwig , Jason Gunthorpe , John Hubbard , Matthew Wilcox , Christopher Lameter , Jan Kara , Linux MM , LKML , linux-rdma Subject: Re: [PATCH 2/2] mm: set PG_dma_pinned on get_user_pages*() Message-ID: <20180626134757.GY28965@dhcp22.suse.cz> References: <20180617012510.20139-3-jhubbard@nvidia.com> <20180617200432.krw36wrcwidb25cj@ziepe.ca> <311eba48-60f1-b6cc-d001-5cc3ed4d76a9@nvidia.com> <20180618081258.GB16991@lst.de> <3898ef6b-2fa0-e852-a9ac-d904b47320d5@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.5 (2018-04-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon 18-06-18 12:21:46, Dan Williams wrote: [...] > I do think we should explore a page flag for pages that are "long > term" pinned. Michal asked for something along these lines at LSF / MM > so that the core-mm can give up on pages that the kernel has lost > lifetime control. Michal, did I capture your ask correctly? I am sorry to be late. I didn't ask for a page flag exactly. I've asked for a way to query for the pin to be temporal or permanent. How that is achieved is another question. Maybe we have some more spare room after recent struct page reorganization but I dunno, to be honest. Maybe we can have an _count offset for these longterm pins. It is not like we are using the whole ref count space, right? Another thing I was asking for is to actually account those longterm pinned pages and apply some control over those. They are basically mlock like and so their usage should better not be unbound. -- Michal Hocko SUSE Labs