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=-0.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 632F9C33CAF for ; Wed, 22 Jan 2020 04:20:08 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 233092465A for ; Wed, 22 Jan 2020 04:20:07 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="QJW4nJcq" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 233092465A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 918286B0003; Tue, 21 Jan 2020 23:20:07 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8C88C6B0005; Tue, 21 Jan 2020 23:20:07 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 804A86B0006; Tue, 21 Jan 2020 23:20:07 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0111.hostedemail.com [216.40.44.111]) by kanga.kvack.org (Postfix) with ESMTP id 660CD6B0005 for ; Tue, 21 Jan 2020 23:20:07 -0500 (EST) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with SMTP id 27A0F180AD804 for ; Wed, 22 Jan 2020 04:20:07 +0000 (UTC) X-FDA: 76403967654.11.9540FD5 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin11.hostedemail.com (Postfix) with ESMTP id 07AEB180F8B80; Wed, 22 Jan 2020 04:20:06 +0000 (UTC) X-HE-Tag: leg34_755dda98c822e X-Filterd-Recvd-Size: 4583 Received: from mail-io1-f65.google.com (mail-io1-f65.google.com [209.85.166.65]) by imf04.hostedemail.com (Postfix) with ESMTP; Wed, 22 Jan 2020 04:20:06 +0000 (UTC) Received: by mail-io1-f65.google.com with SMTP id n21so5296637ioo.10; Tue, 21 Jan 2020 20:20:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=BSyh9fpx1icrJEZvncijB+OYRlF+rgS2wDI+RLPolYk=; b=QJW4nJcqmQLXLklan2ZphK7rHomMBIkB6vmflcqFmzm777ALtPl/aAjaUmuoIeb7e6 KzLOkXdbAEjOb+msiCN17avmbV5XTfalkahmtdrE3P4PtaaIv+ldin/dgQdeSaqyVh2v Zt5HdIOhO7E3CkR4e0RoOGQS4A7iEGwfveh0/6ztG04kVl7W0/r31RurNInw7OYnL7G+ ERxK/xVfQydmkRGUVUwM4b+UszPR9NyIX0e5VI7DhuSK736PzrapIZAtg9tXe30ah+hN b1aLFX+YFel8BKUF/aPCY/WRb1sG/P4qwz7opI0Z0fkO37v6uSXVBNbR+umZviHCuUpw a36A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=BSyh9fpx1icrJEZvncijB+OYRlF+rgS2wDI+RLPolYk=; b=R2azUit2SAMSCU8BpZerOTJkvNwgJL1kdnQbXWylyL37zT+BL4o3RCLGUsD4Ghp2Du ok6+4BlimRDV+95Uou7Tv/PMHyMoIkFtAWdLf6XJ6c54yqnUEKxrLJmACJXRsPZvuWpD q76Lc5PVJObrvYoE2F7ZBeSdiqQSn6ssO5obyU4Q4MtEMqDiy/IPqOTmWdPRyFQ9jZ83 F1S7lYvBRCD9pWWCct48lbdI+GyojoWVAUPt2POdKqr7+lRv4V+fC51vFTaML2Q0608d 3XKl8h49zDTTEdno627Iv91WKGZTiGMB2i0BvreNtLrJRkv8tyCBnbrEt09FMn8Swbdx GUrw== X-Gm-Message-State: APjAAAVWhmJ0XqaIrhKG0EMBG4msgSIzTlAG7BmSCzIdT8dxjf7uHIkQ Gqp3xnaWpGGGD9ax5nKO5VdPQhdL4LM549NAH8Y= X-Google-Smtp-Source: APXvYqxyc7mY3NjURi2D3N2tWdnJrBRqiBBkxY7DCxmIFNgRnG/rsf/vtAajcFrFS9Dv1k8hMs+NPcfq1P4lgRq547U= X-Received: by 2002:a5d:9a85:: with SMTP id c5mr718492iom.266.1579666805589; Tue, 21 Jan 2020 20:20:05 -0800 (PST) MIME-Version: 1.0 References: <20200122023100.75226-1-jglisse@redhat.com> In-Reply-To: <20200122023100.75226-1-jglisse@redhat.com> From: Dan Williams Date: Tue, 21 Jan 2020 20:19:54 -0800 Message-ID: Subject: Re: [LSF/MM/BPF TOPIC] Do not pin pages for various direct-io scheme To: Jerome Glisse Cc: lsf-pc@lists.linux-foundation.org, linux-fsdevel , linux-mm , Jens Axboe , Benjamin LaHaise Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Jan 21, 2020 at 6:34 PM wrote: > > From: J=C3=A9r=C3=B4me Glisse > > Direct I/O does pin memory through GUP (get user page) this does > block several mm activities like: > - compaction > - numa > - migration > ... > > It is also troublesome if the pinned pages are actualy file back > pages that migth go under writeback. In which case the page can > not be write protected from direct-io point of view (see various > discussion about recent work on GUP [1]). This does happens for > instance if the virtual memory address use as buffer for read > operation is the outcome of an mmap of a regular file. > > > With direct-io or aio (asynchronous io) pages are pinned until > syscall completion (which depends on many factors: io size, > block device speed, ...). For io-uring pages can be pinned an > indifinite amount of time. > > > So i would like to convert direct io code (direct-io, aio and > io-uring) to obey mmu notifier and thus allow memory management > and writeback to work and behave like any other process memory. > > For direct-io and aio this mostly gives a way to wait on syscall > completion. For io-uring this means that buffer might need to be > re-validated (ie looking up pages again to get the new set of > pages for the buffer). Impact for io-uring is the delay needed > to lookup new pages or wait on writeback (if necessary). This > would only happens _if_ an invalidation event happens, which it- > self should only happen under memory preissure or for NUMA > activities. This seems to assume that memory pressure and NUMA migration are rare events. Some of the proposed hierarchical memory management schemes [1] might impact that assumption. [1]: http://lore.kernel.org/r/20191101075727.26683-1-ying.huang@intel.com/