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=-1.1 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,URIBL_BLOCKED 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 26B4CC433E0 for ; Thu, 2 Jul 2020 19:58:37 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D883A2088E for ; Thu, 2 Jul 2020 19:58:36 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="ivDhSFxF" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D883A2088E 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 52B426B0005; Thu, 2 Jul 2020 15:58:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4B3F46B0007; Thu, 2 Jul 2020 15:58:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 357696B0008; Thu, 2 Jul 2020 15:58:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0147.hostedemail.com [216.40.44.147]) by kanga.kvack.org (Postfix) with ESMTP id 1C2506B0005 for ; Thu, 2 Jul 2020 15:58:36 -0400 (EDT) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id A84BC180AD806 for ; Thu, 2 Jul 2020 19:58:35 +0000 (UTC) X-FDA: 76994198190.28.skin92_02042c326e8b Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin28.hostedemail.com (Postfix) with ESMTP id 834536C3E for ; Thu, 2 Jul 2020 19:58:35 +0000 (UTC) X-HE-Tag: skin92_02042c326e8b X-Filterd-Recvd-Size: 4818 Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) by imf03.hostedemail.com (Postfix) with ESMTP for ; Thu, 2 Jul 2020 19:58:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1593719914; 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: in-reply-to:in-reply-to:references:references; bh=BCLQe5LsYyu8+abDQmSCBVAAF5BIKekyAy1XEbhzlKo=; b=ivDhSFxFRaZunoCtIeH5Up8PVHF6cVZPZ+dQPnCkQMlRTvOdW+sEqOjONKnTWKwNYW/PKM 5bT37aGKqHguX0qvK3hN3fGnbOhb9LTFJUpMB6ILqRo/s+LpnmRuJ4lvwSCdkZi9VUMGs+ Tli5mRQ3pfKclnLBFkZH5VQfbZ/KQ6s= Received: from mail-oi1-f200.google.com (mail-oi1-f200.google.com [209.85.167.200]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-448-Zep0q5XLN0aU5CAK0qOAxg-1; Thu, 02 Jul 2020 15:58:32 -0400 X-MC-Unique: Zep0q5XLN0aU5CAK0qOAxg-1 Received: by mail-oi1-f200.google.com with SMTP id r186so15966370oih.1 for ; Thu, 02 Jul 2020 12:58:32 -0700 (PDT) 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; bh=BCLQe5LsYyu8+abDQmSCBVAAF5BIKekyAy1XEbhzlKo=; b=CbxjaU/0TpZg9dEZlQbYSJfRPfH5jMHKybjxhZ1A4Nw72W5fNsR2nFg4QofKlA1IpE Id3OiaTMuwouu1qV6v3djL5DB6O4ljvY8ngt0Om0oWQya8hYn4jY7W1t6Ic9mpw3J/Xx gWCMlD42/o0PdInz/g2dac+AvlaeiM1f9H+wF7CUx0Cq6VJZwvBO+bLlPAEzQ6C7Cmrw Q1hEOArybTQINxzdCmUHl2Btj/GYj5kLLzAcVy6ILLlf3vuttw7fxm3rULdPqugYLXpz AkDTIE3/dX9PR+Um91l1optjXV1ffpn5k5CN8pvINodT4R3sGe7HgvXxqDu+UW3PLPMj 22OA== X-Gm-Message-State: AOAM531Kk2hTn4bAqEknYIh4ZbGSqDQWMOFSWerXLbX5W65jf87dwiOw J8DZyqDcLuiHgl5LsOnwpbbs97BioafLtLPQNNqJuHwx/+QSc0rR8A7P6bLEzEyXVt6afAn1DL1 KrgsUgErjxmykcCQm+DxF37XBHcE= X-Received: by 2002:aca:494d:: with SMTP id w74mr7056887oia.72.1593719912199; Thu, 02 Jul 2020 12:58:32 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw1L6FpDy+eyJr4Pj9GcmJ4apoM6n8berudx0byqdTDebDSJ2HNON1jP0UpltmJ0Pff2egMjbmK6hUutlfdI4E= X-Received: by 2002:aca:494d:: with SMTP id w74mr7056871oia.72.1593719911999; Thu, 02 Jul 2020 12:58:31 -0700 (PDT) MIME-Version: 1.0 References: <20200702165120.1469875-1-agruenba@redhat.com> <20200702165120.1469875-3-agruenba@redhat.com> In-Reply-To: From: Andreas Gruenbacher Date: Thu, 2 Jul 2020 21:58:20 +0200 Message-ID: Subject: Re: [RFC 2/4] fs: Add IOCB_NOIO flag for generic_file_read_iter To: Linus Torvalds Cc: Matthew Wilcox , Dave Chinner , linux-fsdevel , Linux-MM , Linux Kernel Mailing List Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=agruenba@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 834536C3E X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam01 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 Thu, Jul 2, 2020 at 8:06 PM Linus Torvalds wrote: > On Thu, Jul 2, 2020 at 9:51 AM Andreas Gruenbacher wrote: > > Add an IOCB_NOIO flag that indicates to generic_file_read_iter that it > > shouldn't trigger any filesystem I/O for the actual request or for > > readahead. This allows to do tentative reads out of the page cache as > > some filesystems allow, and to take the appropriate locks and retry the > > reads only if the requested pages are not cached. > > This looks sane to me, except for this part: > > if (!PageUptodate(page)) { > > - if (iocb->ki_flags & IOCB_NOWAIT) { > > + if (iocb->ki_flags & (IOCB_NOWAIT | IOCB_NOIO)) { > > put_page(page); > > goto would_block; > > } > > This path doesn't actually initiate reads at all - it waits for > existing reads to finish. > > So I think it should only check for IOCB_NOWAIT. > > Of course, if you want to avoid both new reads to be submitted _and_ > avoid waiting for existing pending reads, you should just set both > flags, and you get the semantics you want. So for your case, this may > not make any difference. Indeed, in the gfs2 case, waiting for existing pending reads should be fine. I'll send an update after some testing. Thanks, Andreas