Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1161765AbbKFQYh (ORCPT ); Fri, 6 Nov 2015 11:24:37 -0500 Received: from mout.kundenserver.de ([212.227.126.130]:53864 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1161301AbbKFQYg (ORCPT ); Fri, 6 Nov 2015 11:24:36 -0500 From: Arnd Bergmann To: Catalin Marinas Cc: linux-arm-kernel@lists.infradead.org, Linus Torvalds , Linux Kernel Mailing List , Will Deacon Subject: Re: [GIT PULL] arm64 updates for 4.4 Date: Fri, 06 Nov 2015 17:23:37 +0100 Message-ID: <6253831.r99BEBrMgd@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <20151106160407.GX7637@e104818-lin.cambridge.arm.com> References: <20151104182508.GA28726@e104818-lin.cambridge.arm.com> <6512377.hSX37CgtMC@wuerfel> <20151106160407.GX7637@e104818-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:HcF57jzCF0UDGAZanDMxcnE4MD02eqY6cJl++Pd9H2Box94ARcd ut4pQglUGj0S3QEnnBW8htfDpfQDxBJmhXV9eqzrbgf/t0c1lR01DBBPtZCuMFdTIjZgB4r hO6wQGry6cIlGvGmy0jlR1SqfxT6RWJk3YUTbvo8f8sFJVee2nGrW1j3NeVT2OzYL6x/oyn yEgGsCzMaLrB0cqQFzPMg== X-UI-Out-Filterresults: notjunk:1;V01:K0:iyoUPFBwCbs=:5sDTWta7iFa6zzBoh8B6y/ VKaK4AbIoQNXrrhFH16NhIkrTopGtXtzBJlufKlbH1Zh8jfbs7HFkTBr+ok6x3s2kqBf4v6OD 3wuXWEYEvmv743LQbIgXKjP8bQDcqOskJe53daaNIwbAu+Mts6czw35J4yEL+UhW6FHB/pRdJ iX8lemeyzcTl+FMo/kE6OCMEzVXxkUl9VuW8n1lUiThdo4W8UwWsJbUWrncKRmyTTAMkcfGA+ mMJKgA1iKK7nLW2eB3fbzhUPnU8KrGHaR5B0udfcvGXUY1JfGSerXheXDbOnvK9jCKqNFpgpv CoRj1NotyZK0/cYBKrdU5yqiUzBIGNN2Ev7wjv7C8X0IzFoWHa79eoye4FW+UGFKTcXPq9am1 ENLAugPyYL7lKNNT63Tw/1J68YEJeHxcSrspRvQuhME2ebj6Mkm0Gr733mK1Sefgnfg19kKzi CeWLfFFJl3IYLVjZS6ggxjXEBV3QNsITWpRIAfKB409wR543q4c5aMjMAVqGyi4nFRND5G9MZ ggbEpWrMZfKl5YaJBAAxQka3xLycRYkPrQvm7Z6opkgl18Zpksm7GnQfH9uQFw51FrK46EynK YMjukzL8lmCrKCb1D+7zgj2Q4mYWoqfOSyh+4h35QTmMpz4x5HF/38hHjbZAAgjD5fGNb405T 6Rwuv393mgToB25TQkQUSBI3JB8YM9S0feOEYF2bXhDOraIa7xWOd5LcMesTWwaxmcrG69Gf+ PZ8Y4Frmn8oaPJIG7jqwmfeaJFG6GjHhw7bg+A== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3712 Lines: 82 On Friday 06 November 2015 16:04:08 Catalin Marinas wrote: > On Fri, Nov 06, 2015 at 10:57:58AM +0100, Arnd Bergmann wrote: > > On Thursday 05 November 2015 18:27:18 Catalin Marinas wrote: > > > On Wed, Nov 04, 2015 at 02:55:01PM -0800, Linus Torvalds wrote: > > > > On Wed, Nov 4, 2015 at 10:25 AM, Catalin Marinas wrote: > > > > It's good for single-process loads - if you do a lot of big fortran > > > > jobs, or a lot of big database loads, and nothing else, you're fine. > > > > > > These are some of the arguments from the server camp: specific > > > workloads. > > > > I think (a little overgeneralized), you want 4KB pages for any file > > based mappings, > > In general, yes, but if the main/only workload on your server is mapping > large db files, the memory usage cost may be amortised. This will still only do you good for a database that is read into memory once and not written much, and at that point you can as well use hugepages. The problems for using 64kb page cache on file mappings are - while you normally want some readahead, the larger pages also result in read-behind, so you have to actually transfer data from disk into RAM without ever accessing it. - When you write the data, you have to write the full 64K page because that is the granularity of your dirty bit tracking. So even if you don't care at all about memory consumption, you are still transferring several times more data to and from your drives. As mentioned that can be a win on some storage devices, but usually it's a loss. > > but larger (in some cases much larger) for anonymous > > memory. The last time this came up, I theorized about a way to change > > do_anonymous_page() to always operate on 64KB units on a normal > > 4KB page based kernel, and use the ARM64 contiguous page hint > > to get 64KB TLBs for those pages. > > We have transparent huge pages for this, though the much higher 2MB > size. This would also improve the cost of a TLB miss by walking one > fewer level (point 2 above). I've seen patches for THP on file maps but > I'm not sure what the status is. > > As a test, we could fake a 64KB THP by using a dummy PMD that contains > 16 PTE entries, just to see how the performance goes. But this would > only address point 1 above. Right. > > This could be done compile-time, system-wide, or per-process if > > desired, and should provide performance as good as the current > > 64KB page kernels for almost any server workloads, and in > > some cases much better than that, as long as the hints are > > actually interpreted by the CPU implementation. > > Apart from anonymous mappings, could the file page cache be optimised? > Not all file accesses use mmap() (e.g. gcc compilation seems to do > sequential accesses for the C files the compiler reads), so you don't > always need a full page cache page for a file. > > We could have a feature to allow sharing of partially filled page cache > pages and only break them up if mmap'ed to user. I would think that adds way too much complexity for the gains. > A less optimal > implementation based on the current kernel infrastructure could be > something like a cleancache driver able to store partially filled page > cache pages more efficiently (together with a more aggressive eviction > of such pages from the page cache into the cleancache). Not sure, it could work but may still require changing too much of the way we handle files today. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/