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=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 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 2BD96C4363D for ; Wed, 23 Sep 2020 06:11:08 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id CF4B121D43 for ; Wed, 23 Sep 2020 06:11:07 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CF4B121D43 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=lst.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 55B276B005D; Wed, 23 Sep 2020 02:11:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 50B726B0068; Wed, 23 Sep 2020 02:11:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 421836B006C; Wed, 23 Sep 2020 02:11:07 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0054.hostedemail.com [216.40.44.54]) by kanga.kvack.org (Postfix) with ESMTP id 2C3AD6B005D for ; Wed, 23 Sep 2020 02:11:07 -0400 (EDT) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id EE65E8249980 for ; Wed, 23 Sep 2020 06:11:06 +0000 (UTC) X-FDA: 77293303332.30.blade55_5615ee827154 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin30.hostedemail.com (Postfix) with ESMTP id CAD54180B3AA7 for ; Wed, 23 Sep 2020 06:11:06 +0000 (UTC) X-HE-Tag: blade55_5615ee827154 X-Filterd-Recvd-Size: 3253 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by imf38.hostedemail.com (Postfix) with ESMTP for ; Wed, 23 Sep 2020 06:11:06 +0000 (UTC) Received: by verein.lst.de (Postfix, from userid 2407) id DCEC767373; Wed, 23 Sep 2020 08:11:02 +0200 (CEST) Date: Wed, 23 Sep 2020 08:11:02 +0200 From: Christoph Hellwig To: Tvrtko Ursulin Cc: Christoph Hellwig , Matthew Wilcox , Juergen Gross , Stefano Stabellini , linux-mm@kvack.org, Peter Zijlstra , Boris Ostrovsky , x86@kernel.org, linux-kernel@vger.kernel.org, Minchan Kim , dri-devel@lists.freedesktop.org, xen-devel@lists.xenproject.org, Andrew Morton , intel-gfx@lists.freedesktop.org, Nitin Gupta , Chris Wilson , Matthew Auld Subject: Re: [Intel-gfx] [PATCH 3/6] drm/i915: use vmap in shmem_pin_map Message-ID: <20200923061102.GA15762@lst.de> References: <20200918163724.2511-1-hch@lst.de> <20200918163724.2511-4-hch@lst.de> <20200921191157.GX32101@casper.infradead.org> <20200922062249.GA30831@lst.de> <43d10588-2033-038b-14e4-9f41cd622d7b@linux.intel.com> <20200922143141.GA26637@lst.de> <20200922163346.GA1701@lst.de> <1b05b9d6-a14c-85cd-0728-d0d40c9ff84b@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1b05b9d6-a14c-85cd-0728-d0d40c9ff84b@linux.intel.com> User-Agent: Mutt/1.5.17 (2007-11-01) 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 Tue, Sep 22, 2020 at 06:04:37PM +0100, Tvrtko Ursulin wrote: > Only reason I can come up with now is if mapping side is on a latency > sensitive path, while un-mapping is lazy/delayed so can be more costly. > Then fast map and extra cost on unmap may make sense. In general yes. But compared to the overall operations a small kmalloc is in the noise, so I'd really like to see numbers. > It more applies to the other i915 patch, which implements a much more used > API, but whether or not we can demonstrate any difference in the perf > profiles I couldn't tell you without trying to collect some. The other patch keeps the stack, as avoiding it would not simplify the code as significantly. I still doubt it is all that useful, though. >> We could do vmalloc_to_page, but that is fairly expensive (not as bad >> as reading from the page cache..). Are you really worried about the >> allocation? > > Not so much given how we don't even use shmem_pin_map outside selftests. > > If we start using it I expect it will be for tiny objects anyway. Only if > they end up being pinned for the lifetime of the driver, it may be a > pointless waste of memory compared to the downsides of vmalloc_to_page. But > we can revisit this particular edge case optimization if the need arises. For tiny object we could either look into using kmap, or in fact ensure the shmem files aren't in highmem, in which case you could always use single-page mappings without any extra mapping.