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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B69F5C433EF for ; Mon, 27 Sep 2021 09:24:17 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 443776103B for ; Mon, 27 Sep 2021 09:24:16 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 443776103B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id D834E940007; Mon, 27 Sep 2021 05:24:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D342D6B0073; Mon, 27 Sep 2021 05:24:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BFD0B940007; Mon, 27 Sep 2021 05:24:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0127.hostedemail.com [216.40.44.127]) by kanga.kvack.org (Postfix) with ESMTP id B12246B0072 for ; Mon, 27 Sep 2021 05:24:15 -0400 (EDT) Received: from smtpin36.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 70EA131EC8 for ; Mon, 27 Sep 2021 09:24:15 +0000 (UTC) X-FDA: 78632817270.36.2F2A516 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf28.hostedemail.com (Postfix) with ESMTP id 12B9990000A2 for ; Mon, 27 Sep 2021 09:24:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1632734654; 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=Jp02F8QsbdFJf3j7YUtw+WzbWBUYKqtVXobt73sBmVU=; b=jTLCXhEJsN/YFgZ6DOPxygJEk7ybIIeRVqqyyOLsqn7l3dmXiEOaY/t3LKcNip5YeIs+4p BQ97EMr0sH9utewYLuKXSPXSUCesRgTlUJR76YIHyVncXhsdtHa2FuN9+ciy99TTjYa9vE kf/Yy12ZVjW8lNyRxIIoK77t1MCESLY= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-328-rKQuQkzjOUOCd3TLVha2Cw-1; Mon, 27 Sep 2021 05:24:13 -0400 X-MC-Unique: rKQuQkzjOUOCd3TLVha2Cw-1 Received: by mail-wr1-f70.google.com with SMTP id j15-20020a5d564f000000b00160698bf7e9so483920wrw.13 for ; Mon, 27 Sep 2021 02:24:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=Jp02F8QsbdFJf3j7YUtw+WzbWBUYKqtVXobt73sBmVU=; b=5k5kz+xegos70Lw1sFkF0cAHCqzb4iiGaHzaLgtwahPhAlA6tnET20rornPTj8rLO/ Ka8oV4J4jMifIcqKYDS4uti6woS/PC79ujgyqgGnbWETNA1lDjNzVQ+gaN3iAhtOmJcV D7WRd3u0MUcIubNWcWTHiaIP3FLqmsSwte3lp1MuE/6+aghnfENR+hQCUTTLPo4hjZdP puFx96ryUEO8kHS9ExGv0446Dtvd30Wc1AMo66IJOQotgigSwUDHs2LWjR3NZ6AL+kmY 7CVYdR5U+l0jq3RaMsf6yu9YrY7K2PIjP6qyiQsSbo3t8/4NcaswOcZIBUoRntP3lySH 9ZUA== X-Gm-Message-State: AOAM533HPP5C5V4/qrHYkwJUXCnllBVqvtpcwy3FIKKkYwm1kn9berl+ CLto+zJekpBcJI/+xVALZEQd+kqQaxolnJddkUNg2ODUXMcXYJIJYt77oFwrLcIcrTSZwffxCFN HXDYs/L/PZm8= X-Received: by 2002:a5d:6c6e:: with SMTP id r14mr25885736wrz.319.1632734652196; Mon, 27 Sep 2021 02:24:12 -0700 (PDT) X-Google-Smtp-Source: ABdhPJygT4hurYn4CrYnSURJEf3gzm1/6pBYoxY+DcI2dUbDLFXRFlGkxtYsqSUAIJKK4I3S6u0tsw== X-Received: by 2002:a5d:6c6e:: with SMTP id r14mr25885610wrz.319.1632734650963; Mon, 27 Sep 2021 02:24:10 -0700 (PDT) Received: from [192.168.3.132] (p5b0c654d.dip0.t-ipconnect.de. [91.12.101.77]) by smtp.gmail.com with ESMTPSA id g21sm622229wmk.10.2021.09.27.02.24.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 27 Sep 2021 02:24:10 -0700 (PDT) Subject: Re: [RFC PATCH 0/8] mm/madvise: support process_madvise(MADV_DONTNEED) To: Nadav Amit , Andrew Morton Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Peter Xu , Nadav Amit , Andrea Arcangeli , Minchan Kim , Colin Cross , Suren Baghdasarya , Mike Rapoport References: <20210926161259.238054-1-namit@vmware.com> From: David Hildenbrand Organization: Red Hat Message-ID: <7ce823c8-cfbf-cc59-9fc7-9aa3a79740c3@redhat.com> Date: Mon, 27 Sep 2021 11:24:09 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <20210926161259.238054-1-namit@vmware.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 12B9990000A2 X-Stat-Signature: ti489djqyamxciy1qfus8zj51b39wktz Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=jTLCXhEJ; spf=none (imf28.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Rspamd-Server: rspam06 X-HE-Tag: 1632734654-878504 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000010, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 26.09.21 18:12, Nadav Amit wrote: > From: Nadav Amit > > The goal of these patches is to add support for > process_madvise(MADV_DONTNEED). Yet, in the process some (arguably) > useful cleanups, a bug fix and performance enhancements are performed. > > The patches try to consolidate the logic across different behaviors, and > to a certain extent overlap/conflict with an outstanding patch that does > something similar [1]. This consolidation however is mostly orthogonal > to the aforementioned one and done in order to clarify what is done in > respect to locks and TLB for each behavior and to batch these operations > more efficiently on process_madvise(). > > process_madvise(MADV_DONTNEED) is useful for two reasons: (a) it allows > userfaultfd monitors to unmap memory from monitored processes; and (b) > it is more efficient than madvise() since it is vectored and batches TLB > flushes more aggressively. MADV_DONTNEED on MAP_PRIVATE memory is a target-visible operation; this is very different to all the other process_madvise() calls we allow, which are merely hints, but the target cannot be broken . I don't think this is acceptable. -- Thanks, David / dhildenb