Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp1631810imm; Thu, 18 Oct 2018 01:17:49 -0700 (PDT) X-Google-Smtp-Source: ACcGV61UISoXMH8+bDM4HKx81DB/rKGVophEkcBSsjiuVgIPZX/6Q0i3YdRcf5T2V1C97y2HFqOm X-Received: by 2002:a62:1e42:: with SMTP id e63-v6mr21596629pfe.149.1539850669882; Thu, 18 Oct 2018 01:17:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539850669; cv=none; d=google.com; s=arc-20160816; b=anVdt6zAMOH0/X9Olj1MZWMByBEIEpCrOr7dYq3OpqUCNDU5Fg+0EcRstd2jPx4rbX s/7RDaIo5kJqLdoDJuwoxW589UhA2lmQgCO1wxKqEMjFDHMi6inwgNwvMgLN0R+TPSB4 A5qpoTL8+SU1rqxw2f1JZgvxLV0CeSCFiWHd97vHoEQ6JbgVH6kzuOFecJCld++8bzEN XSw6O4gMLoC8ZSwTYZrdvz7qltFQQHz2+yAjFLhiPvAN0hktodlMEjFHc/OiPoSvRyAp OtRZHmV4SrSu3CYkN60v6AQxxu2fJ1l9Hv2A8f6l5SjJdRwz22lGviBJ5ES1fBbzUZRb T6PA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=SGhwyOWb26ryN5SDsZ8E9QKK+FtbMZrjAoBY2FFcyRw=; b=u3rYmuvp85ftXfzZBuNqccAoKn7qoxHDG+psiqSLBO157fpwhCEEr7fdiE7TVbuutD t9KLReae1U+qU/qURKSU+Sqqqyvzptk1ZlrluWsX1Obtt7nQcYs5sXo8/GFJmApBwowH IzYOQCgNBuxz3IdXXZqqIhJWIVHCVHUwdz1aTLOV8rqlUujxdxZSLwwmGm4KJfCrDKUR yaWnQZlmna5WlfbEU2HkdiZKtPwk8lx7IHbzkt5x59kA/EAvE/ot01Zh9S0HuwA9nVdw ++i2KZN4L077PXdVwxfvOnRWi7KI6ZYV2c14rOBIBGqib2plDAjW327ndeRxh5PHY0Kj WXDw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x33-v6si16158300plb.437.2018.10.18.01.17.34; Thu, 18 Oct 2018 01:17:49 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727563AbeJRQPt (ORCPT + 99 others); Thu, 18 Oct 2018 12:15:49 -0400 Received: from mx2.suse.de ([195.135.220.15]:44914 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727376AbeJRQPt (ORCPT ); Thu, 18 Oct 2018 12:15:49 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 488B5AFD1; Thu, 18 Oct 2018 08:15:57 +0000 (UTC) Date: Thu, 18 Oct 2018 10:15:52 +0200 From: Michal Hocko To: Chris Wilson Cc: Kuo-Hsin Yang , linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org, linux-mm@kvack.org, akpm@linux-foundation.org, peterz@infradead.org, dave.hansen@intel.com, corbet@lwn.net, hughd@google.com, joonas.lahtinen@linux.intel.com, marcheu@chromium.org, hoegsberg@chromium.org Subject: Re: [PATCH 2/2] drm/i915: Mark pinned shmemfs pages as unevictable Message-ID: <20181018081552.GZ18839@dhcp22.suse.cz> References: <20181016174300.197906-1-vovoy@chromium.org> <20181016174300.197906-3-vovoy@chromium.org> <20181016182155.GW18839@dhcp22.suse.cz> <153971466599.22931.16793398326492316920@skylake-alporthouse-com> <153984580501.19935.11456945882099910977@skylake-alporthouse-com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <153984580501.19935.11456945882099910977@skylake-alporthouse-com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu 18-10-18 07:56:45, Chris Wilson wrote: > Quoting Chris Wilson (2018-10-16 19:31:06) > > Fwiw, the shmem_unlock_mapping() call feels quite expensive, almost > > nullifying the advantage gained from not walking the lists in reclaim. > > I'll have better numbers in a couple of days. > > Using a test ("igt/benchmarks/gem_syslatency -t 120 -b -m" on kbl) > consisting of cycletest with a background load of trying to allocate + > populate 2MiB (to hit thp) while catting all files to /dev/null, the > result of using mapping_set_unevictable is mixed. I haven't really read through your report completely yet but I wanted to point out that the above test scenario is unlikely show the real effect of the LRU scanning overhead because shmem pages do live on the anonymous LRU list. With a plenty of file page cache available we do not even scan anonymous LRU lists. You would have to generate a swapout workload to test this properly. On the other hand if mapping_set_unevictable has really a measurably bad performance impact then this is probably not worth much because most workloads are swap modest. -- Michal Hocko SUSE Labs