Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753319AbbKGK4v (ORCPT ); Sat, 7 Nov 2015 05:56:51 -0500 Received: from mail-wi0-f194.google.com ([209.85.212.194]:33535 "EHLO mail-wi0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753199AbbKGK4r (ORCPT ); Sat, 7 Nov 2015 05:56:47 -0500 Date: Sat, 7 Nov 2015 11:56:44 +0100 (CET) From: Hans Ulli Kroll X-X-Sender: elektroman@T520.local To: Arnd Bergmann cc: Catalin Marinas , linux-arm-kernel@lists.infradead.org, Linus Torvalds , Linux Kernel Mailing List , Will Deacon Subject: Re: [GIT PULL] arm64 updates for 4.4 In-Reply-To: <6253831.r99BEBrMgd@wuerfel> Message-ID: References: <20151104182508.GA28726@e104818-lin.cambridge.arm.com> <6512377.hSX37CgtMC@wuerfel> <20151106160407.GX7637@e104818-lin.cambridge.arm.com> <6253831.r99BEBrMgd@wuerfel> User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2735 Lines: 69 Hi On Fri, 6 Nov 2015, Arnd Bergmann wrote: > 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. > there is also a maybe a bigger problem. I know this from my Zyxel NAS540, this thing is build around the Mindspeed Comcerto 2000 SoC Zyxel is currently rolling back to support 4k page sizeses in upcommig 5.10 firmware release, because Minspeed did some stupid thing : It's not possible to use some standard ARMv7 toolchain and build your own/needed userspace tools. And this in change which causes the pain diff --git a/arch/arm/include/asm/elf.h b/arch/arm/include/asm/elf.h -#define ELF_EXEC_PAGESIZE 4096 +#define ELF_EXEC_PAGESIZE (PAGE_SIZE) The SoC is mostly build from off the shelf IP's SATA, NAND, SPI and so on The only thing which is completly braindead is MAC It's using some kind of VLAN tagging to support tree ports, only one descriptor chain for all three interfaces. Hans Ulli -- 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/