From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755786AbeASJHm (ORCPT ); Fri, 19 Jan 2018 04:07:42 -0500 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:48648 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1755692AbeASJGe (ORCPT ); Fri, 19 Jan 2018 04:06:34 -0500 Subject: Re: [PATCH v2 3/5] powerpc/mm: Allow more than 16 low slices To: Christophe LEROY , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Scott Wood Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org References: <49148d07955d3e5f963cedf9adcfcc37c3e03ef4.1516179904.git.christophe.leroy@c-s.fr> <1c9752ac98fd3278ef448e2553053c287af42b3f.1516179904.git.christophe.leroy@c-s.fr> <87po66z1w2.fsf@linux.vnet.ibm.com> From: "Aneesh Kumar K.V" Date: Fri, 19 Jan 2018 14:36:22 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 x-cbid: 18011909-0008-0000-0000-00000931766D X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00008405; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000247; SDB=6.00977204; UDB=6.00495441; IPR=6.00757126; BA=6.00005782; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00019125; XFM=3.00000015; UTC=2018-01-19 09:06:30 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18011909-0009-0000-0000-0000459EA560 Message-Id: <26a6d845-cf38-d8c6-5f54-a57ddb2a5a77@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-01-19_04:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1801190118 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/19/2018 02:29 PM, Christophe LEROY wrote: > > > Le 19/01/2018 à 09:30, Aneesh Kumar K.V a écrit : >> Christophe Leroy writes: >> >>> While the implementation of the "slices" address space allows >>> a significant amount of high slices, it limits the number of >>> low slices to 16 due to the use of a single u64 low_slices_psize >>> element in struct mm_context_t >>> >>> On the 8xx, the minimum slice size is the size of the area >>> covered by a single PMD entry, ie 4M in 4K pages mode and 64M in >>> 16K pages mode. This means we could have resp. up to 1024 and 64 >>> slices. >>> >>> In order to override this limitation, this patch switches the >>> handling of low_slices to BITMAPs as done already for high_slices. >> >> Does it have a performance impact. When we switched high_slices >> that was one of the question asked. Now with a topdown search we should >> mostly be using the high_slices. But it will good to get numbers for >> ppc64 for this change. > > It should have almost no performance impact at all, because all bitmap > functions used a simplified way when the number of bits is small and > constant: > > -    ret->low_slices = 0; > +    slice_bitmap_zero(ret->low_slices, SLICE_NUM_LOW); > > > static inline void bitmap_zero(unsigned long *dst, unsigned int nbits) > { >     if (small_const_nbits(nbits)) >         *dst = 0UL; >     else { >         unsigned int len = BITS_TO_LONGS(nbits) * sizeof(unsigned long); >         memset(dst, 0, len); >     } > } > > > > -    dst->low_slices |= src->low_slices; > +    slice_bitmap_or(dst->low_slices, dst->low_slices, src->low_slices, > +            SLICE_NUM_LOW); > > > static inline void bitmap_or(unsigned long *dst, const unsigned long *src1, >             const unsigned long *src2, unsigned int nbits) > { >     if (small_const_nbits(nbits)) >         *dst = *src1 | *src2; >     else >         __bitmap_or(dst, src1, src2, nbits); > } > > > may be capture that in commit message saying since we are 64 bit on ppc64 there is no impact there? -aneesh