From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Williams Subject: Re: [PATCH 1/2] mm: introduce put_user_page*(), placeholder versions Date: Tue, 15 Jan 2019 18:01:09 -0800 Message-ID: References: <294bdcfa-5bf9-9c09-9d43-875e8375e264@nvidia.com> <20190112024625.GB5059@redhat.com> <20190114145447.GJ13316@quack2.suse.cz> <20190114172124.GA3702@redhat.com> <20190115080759.GC29524@quack2.suse.cz> <20190115171557.GB3696@redhat.com> <752839e6-6cb3-a6aa-94cb-63d3d4265934@nvidia.com> <20190115221205.GD3696@redhat.com> <99110c19-3168-f6a9-fbde-0a0e57f67279@nvidia.com> <20190116015610.GH3696@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Cc: John Hubbard , Jan Kara , Matthew Wilcox , Dave Chinner , John Hubbard , Andrew Morton , Linux MM , tom@talpey.com, Al Viro , benve@cisco.com, Christoph Hellwig , Christopher Lameter , "Dalessandro, Dennis" , Doug Ledford , Jason Gunthorpe , Michal Hocko , Mike Marciniszyn , rcampbell@nvidia.com, Linux Kernel Mailing List , linux-fsdevel To: Jerome Glisse Return-path: In-Reply-To: <20190116015610.GH3696@redhat.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Tue, Jan 15, 2019 at 5:56 PM Jerome Glisse wrote: > On Tue, Jan 15, 2019 at 04:44:41PM -0800, John Hubbard wrote: [..] > To make it clear. > > Lock code: > GUP() > ... > lock_page(page); > if (PageWriteback(page)) { > unlock_page(page); > wait_stable_page(page); > goto retry; > } > atomic_add(page->refcount, PAGE_PIN_BIAS); > unlock_page(page); > > test_set_page_writeback() > bool pinned = false; > ... > pinned = page_is_pin(page); // could be after TestSetPageWriteback > TestSetPageWriteback(page); > ... > return pinned; > > Memory barrier: > GUP() > ... > atomic_add(page->refcount, PAGE_PIN_BIAS); > smp_mb(); > if (PageWriteback(page)) { > atomic_add(page->refcount, -PAGE_PIN_BIAS); > wait_stable_page(page); > goto retry; > } > > test_set_page_writeback() > bool pinned = false; > ... > TestSetPageWriteback(page); > smp_wmb(); > pinned = page_is_pin(page); > ... > return pinned; > > > One is not more complex than the other. One can contend, the other > will _never_ contend. The complexity is in the validation of lockless algorithms. It's easier to reason about locks than barriers for the long term maintainability of this code. I'm with Jan and John on wanting to explore lock_page() before a barrier-based scheme. 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.0 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS autolearn=unavailable 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 F3214C43387 for ; Wed, 16 Jan 2019 02:01:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B92532082F for ; Wed, 16 Jan 2019 02:01:22 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=intel-com.20150623.gappssmtp.com header.i=@intel-com.20150623.gappssmtp.com header.b="ZcjEfkym" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728090AbfAPCBW (ORCPT ); Tue, 15 Jan 2019 21:01:22 -0500 Received: from mail-ot1-f65.google.com ([209.85.210.65]:45003 "EHLO mail-ot1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727550AbfAPCBV (ORCPT ); Tue, 15 Jan 2019 21:01:21 -0500 Received: by mail-ot1-f65.google.com with SMTP id f18so4635295otl.11 for ; Tue, 15 Jan 2019 18:01:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WlE9B/Ts/5kmVoT/yhWaCE6Kcc8ieumx6zA59spU9wM=; b=ZcjEfkymRud+McOoMAGPl889LVxFLq9vkOsP1QNATBMKgaqrQOPz6MtyzbcVfyGAkc 0Yl06YQHlc1R1J/eeVn+mK/RQbunD0e5K0xdkXRdFKepSghykgphHf2IA24dbwScw3c1 itLPsab/d8bvPzuZhvdz77tqG2cxAjfkxLIQMZgmaZSx1x+m/B8lSirYZc1uis66F72i Ar8XgfQnAvw2PkL+Fi981CILyrHtdEXxpxdNpYWCwUlp4hcjOEfGJqROMW3MzFO5GKIT AXJ/JM/OOHMqjunkHi2HPmnkLGtPXys7dyGWhGmRYdKdraXzLm+KdFihB49Lx9kVJuqY HDgQ== 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=WlE9B/Ts/5kmVoT/yhWaCE6Kcc8ieumx6zA59spU9wM=; b=OibrKofZpURpk7zU/40cQk/Jfx+20E2nPQo3QcG71aP1MUVoKx2SFwE+6KSZw1MDqf o+7bebLjy4Q23IVlM6w45LxjMaMJNHzta5FCwPI91ARIvNeNWkRXl1/VdV8/wnymIDaj KDhpqzYi0q9USxfdG+m89zrwQkmdV63n77+f76TuAqfuyIFa/tHYuhzTiFZT4dKHpXJP 6G4BsvGVgg1knZMSF9NyrIBmt/CWVdldP74oFYcypWMR/r5358EMNdRMRphwcpN+taeI 0PgWOygOm2o1+HDnDWPlXxqcFsHwAk6mcR+3xGr88jyPyUmMxIaLtQ1Myv1jisZM3EC8 TJCA== X-Gm-Message-State: AJcUukdxp5N6qBB0VKZS1grEyVrfg0zS4zdtCSu3q65ra8x49FTYC+yQ I8oElAIN3bRdMZnLfCrM7jYxagwXTS5RiNd0N/RA4g== X-Google-Smtp-Source: ALg8bN6k8VrGhTAZgUFWUdDqFrNSRRsUbvN1vUk1Q2Umc4ZqtlUPFAky5MZDBtlAzecZCdF4Uq+DYAZ1LrB+c1jrak8= X-Received: by 2002:a9d:5cc2:: with SMTP id r2mr4061912oti.367.1547604081096; Tue, 15 Jan 2019 18:01:21 -0800 (PST) MIME-Version: 1.0 References: <294bdcfa-5bf9-9c09-9d43-875e8375e264@nvidia.com> <20190112024625.GB5059@redhat.com> <20190114145447.GJ13316@quack2.suse.cz> <20190114172124.GA3702@redhat.com> <20190115080759.GC29524@quack2.suse.cz> <20190115171557.GB3696@redhat.com> <752839e6-6cb3-a6aa-94cb-63d3d4265934@nvidia.com> <20190115221205.GD3696@redhat.com> <99110c19-3168-f6a9-fbde-0a0e57f67279@nvidia.com> <20190116015610.GH3696@redhat.com> In-Reply-To: <20190116015610.GH3696@redhat.com> From: Dan Williams Date: Tue, 15 Jan 2019 18:01:09 -0800 Message-ID: Subject: Re: [PATCH 1/2] mm: introduce put_user_page*(), placeholder versions To: Jerome Glisse Cc: John Hubbard , Jan Kara , Matthew Wilcox , Dave Chinner , John Hubbard , Andrew Morton , Linux MM , tom@talpey.com, Al Viro , benve@cisco.com, Christoph Hellwig , Christopher Lameter , "Dalessandro, Dennis" , Doug Ledford , Jason Gunthorpe , Michal Hocko , Mike Marciniszyn , rcampbell@nvidia.com, Linux Kernel Mailing List , linux-fsdevel Content-Type: text/plain; charset="UTF-8" Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org Message-ID: <20190116020109.HLq3Y9FGBM25EwvHOST-PIn-T2dpRHBs3_ZKaobVmIk@z> On Tue, Jan 15, 2019 at 5:56 PM Jerome Glisse wrote: > On Tue, Jan 15, 2019 at 04:44:41PM -0800, John Hubbard wrote: [..] > To make it clear. > > Lock code: > GUP() > ... > lock_page(page); > if (PageWriteback(page)) { > unlock_page(page); > wait_stable_page(page); > goto retry; > } > atomic_add(page->refcount, PAGE_PIN_BIAS); > unlock_page(page); > > test_set_page_writeback() > bool pinned = false; > ... > pinned = page_is_pin(page); // could be after TestSetPageWriteback > TestSetPageWriteback(page); > ... > return pinned; > > Memory barrier: > GUP() > ... > atomic_add(page->refcount, PAGE_PIN_BIAS); > smp_mb(); > if (PageWriteback(page)) { > atomic_add(page->refcount, -PAGE_PIN_BIAS); > wait_stable_page(page); > goto retry; > } > > test_set_page_writeback() > bool pinned = false; > ... > TestSetPageWriteback(page); > smp_wmb(); > pinned = page_is_pin(page); > ... > return pinned; > > > One is not more complex than the other. One can contend, the other > will _never_ contend. The complexity is in the validation of lockless algorithms. It's easier to reason about locks than barriers for the long term maintainability of this code. I'm with Jan and John on wanting to explore lock_page() before a barrier-based scheme.