From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 3zrCNp4zMszF1Kv for ; Tue, 27 Feb 2018 20:01:30 +1100 (AEDT) Received: from pps.filterd (m0098396.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1R90Bsm053869 for ; Tue, 27 Feb 2018 04:01:27 -0500 Received: from e06smtp14.uk.ibm.com (e06smtp14.uk.ibm.com [195.75.94.110]) by mx0a-001b2d01.pphosted.com with ESMTP id 2gd1xndskb-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Tue, 27 Feb 2018 04:01:22 -0500 Received: from localhost by e06smtp14.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 27 Feb 2018 09:01:10 -0000 From: "Aneesh Kumar K.V" To: Christophe Leroy , Nicholas Piggin Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org Subject: Re: [RFC REBASED 5/5] powerpc/mm/slice: use the dynamic high slice size to limit bitmap operations In-Reply-To: <5badd882663833576c10b8aafe235fe1e443f119.1518382747.git.christophe.leroy@c-s.fr> References: <02a62db83282b5ef3e0e8281fdc46fa91beffc86.1518382747.git.christophe.leroy@c-s.fr> <5badd882663833576c10b8aafe235fe1e443f119.1518382747.git.christophe.leroy@c-s.fr> Date: Tue, 27 Feb 2018 14:31:07 +0530 MIME-Version: 1.0 Content-Type: text/plain Message-Id: <87bmga7qng.fsf@linux.vnet.ibm.com> List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Christophe Leroy writes: > The number of high slices a process might use now depends on its > address space size, and what allocation address it has requested. > > This patch uses that limit throughout call chains where possible, > rather than use the fixed SLICE_NUM_HIGH for bitmap operations. > This saves some cost for processes that don't use very large address > spaces. I haven't really looked at the final code. One of the issue we had was with the below scenario. mmap(addr, len) where addr < 128TB and addr+len > 128TB We want to make sure we build the mask such that we don't find the addr available. -aneesh