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 AAF50C43144 for ; Wed, 27 Jun 2018 11:32:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5A4372646C for ; Wed, 27 Jun 2018 11:32:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5A4372646C 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 S964793AbeF0LcZ (ORCPT ); Wed, 27 Jun 2018 07:32:25 -0400 Received: from mx2.suse.de ([195.135.220.15]:43445 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933185AbeF0LcX (ORCPT ); Wed, 27 Jun 2018 07:32:23 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (charybdis-ext-too.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 4693DAF2D; Wed, 27 Jun 2018 11:32:22 +0000 (UTC) Date: Wed, 27 Jun 2018 13:32:21 +0200 From: Michal Hocko To: Jan Kara Cc: Dan Williams , John Hubbard , Christoph Hellwig , Jason Gunthorpe , John Hubbard , Matthew Wilcox , Christopher Lameter , Linux MM , LKML , linux-rdma Subject: Re: [PATCH 2/2] mm: set PG_dma_pinned on get_user_pages*() Message-ID: <20180627113221.GO32348@dhcp22.suse.cz> References: <20180617200432.krw36wrcwidb25cj@ziepe.ca> <311eba48-60f1-b6cc-d001-5cc3ed4d76a9@nvidia.com> <20180618081258.GB16991@lst.de> <3898ef6b-2fa0-e852-a9ac-d904b47320d5@nvidia.com> <20180626134757.GY28965@dhcp22.suse.cz> <20180626164825.fz4m2lv6hydbdrds@quack2.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180626164825.fz4m2lv6hydbdrds@quack2.suse.cz> User-Agent: Mutt/1.10.0 (2018-05-17) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue 26-06-18 18:48:25, Jan Kara wrote: > On Tue 26-06-18 15:47:57, Michal Hocko wrote: > > 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? > > Matthew had an interesting idea to pull pinned pages completely out from > any LRU and reuse that space in struct page for pinned refcounts. From some > initial investigation (read on elsewhere in this thread) it looks doable. I > was considering offsetting in refcount as well but on 32-bit architectures > there's not that many bits that I'd be really comfortable with that > solution... I am really slow at following up this discussion. The problem I would see with off-lru pages is that this can quickly turn into a weird reclaim behavior. Especially when we are talking about a lot of memory. It is true that such pages wouldn't be reclaimable directly but could poke them in some way if we see too many of them while scanning LRU. Not that this is a fundamental block stopper but this is the first thing that popped out when thinking about such a solution. Maybe it is a good start though. Appart from that, do we really care about 32b here? Big DIO, IB users seem to be 64b only AFAIU. -- Michal Hocko SUSE Labs