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.9 required=3.0 tests=DKIMWL_WL_HIGH,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 BAF7CC2D0DB for ; Wed, 22 Jan 2020 16:57:41 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 802AD24656 for ; Wed, 22 Jan 2020 16:57:41 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="UJ/xYUyu" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 802AD24656 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 1D6E36B0008; Wed, 22 Jan 2020 11:57:41 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 187466B000A; Wed, 22 Jan 2020 11:57:41 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 09DA06B000C; Wed, 22 Jan 2020 11:57:41 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0250.hostedemail.com [216.40.44.250]) by kanga.kvack.org (Postfix) with ESMTP id EACE46B0008 for ; Wed, 22 Jan 2020 11:57:40 -0500 (EST) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with SMTP id 4A55B8248076 for ; Wed, 22 Jan 2020 16:57:40 +0000 (UTC) X-FDA: 76405876680.10.honey56_25bca44e0393d X-HE-Tag: honey56_25bca44e0393d X-Filterd-Recvd-Size: 4586 Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.61]) by imf38.hostedemail.com (Postfix) with ESMTP for ; Wed, 22 Jan 2020 16:57:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1579712258; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=nCuK9gG+XzyBqAKZyvtcNiJmI9iChL+W/5OmSfkPvfQ=; b=UJ/xYUyuL7HV+7uAN47JlFZh2jV6lu7xO4WN37ODW/BVPLB55dkzhiT9yE4rMRS7WyVhk+ GFibRE0wydD1ZFsu2udqmDeSCq82lr1f3SDKUQ9/YXeOfdHdZdbNbf8rksz9G4+jQ/QYn5 jGwpMS6hXZYI6kC930nD6lGhNteQBl4= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-302-OsP4GJsXNx-3zmg_d1TIBg-1; Wed, 22 Jan 2020 11:57:32 -0500 X-MC-Unique: OsP4GJsXNx-3zmg_d1TIBg-1 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 mimecast-mx01.redhat.com (Postfix) with ESMTPS id 45AB71088381; Wed, 22 Jan 2020 16:57:31 +0000 (UTC) Received: from redhat.com (ovpn-112-42.rdu2.redhat.com [10.10.112.42]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 38D5D8BE31; Wed, 22 Jan 2020 16:57:28 +0000 (UTC) Date: Wed, 22 Jan 2020 08:54:27 -0800 From: Jerome Glisse To: Jens Axboe Cc: Michal Hocko , lsf-pc@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, Benjamin LaHaise Subject: Re: [LSF/MM/BPF TOPIC] Do not pin pages for various direct-io scheme Message-ID: <20200122165427.GA6009@redhat.com> References: <20200122023100.75226-1-jglisse@redhat.com> <20200122045723.GC76712@redhat.com> <20200122115926.GW29276@dhcp22.suse.cz> <015647b0-360c-c9ac-ac20-405ae0ec4512@kernel.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <015647b0-360c-c9ac-ac20-405ae0ec4512@kernel.dk> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 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 Wed, Jan 22, 2020 at 08:12:51AM -0700, Jens Axboe wrote: > On 1/22/20 4:59 AM, Michal Hocko wrote: > > On Tue 21-01-20 20:57:23, Jerome Glisse wrote: > >> We can also discuss what kind of knobs we want to expose so that > >> people can decide to choose the tradeof themself (ie from i want low > >> latency io-uring and i don't care wether mm can not do its business;= to > >> i want mm to never be impeded in its business and i accept the extra > >> latency burst i might face in io operations). > >=20 > > I do not think it is a good idea to make this configurable. How can > > people sensibly choose between the two without deep understanding of > > internals? >=20 > Fully agree, we can't just punt this to a knob and call it good, that's > a typical fallacy of core changes. And there is only one mode for > io_uring, and that's consistent low latency. If this change introduces > weird reclaim, compaction or migration latencies, then that's a > non-starter as far as I'm concerned. >=20 > And what do those two settings even mean? I don't even know, and a user > sure as hell doesn't either. >=20 > io_uring pins two types of pages - registered buffers, these are used > for actual IO, and the rings themselves. The rings are not used for IO, > just used to communicate between the application and the kernel. So, do we still want to solve file back pages write back if page in ubuffer are from a file ? Also we can introduce a flag when registering buffer that allows to register buffer without pining and thus avoid the RLIMIT_MEMLOCK at the cost of possible latency spike. Then user registering the buffer knows what he gets. Maybe it would be good to test, it might stay in the noise, then it might be a good thing to do. Also they are strategy to avoid latency spike for instance we can block/force skip mm invalidation if buffer has pending/running io in the ring ie only have buffer invalidation happens when there is no pending/running submission entry. We can also pick what kind of invalidation we allow (compaction, migration, ...) and thus limit the scope and likelyhood of invalidation. Cheers, J=E9r=F4me