Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752080AbeAQFX4 convert rfc822-to-8bit (ORCPT + 1 other); Wed, 17 Jan 2018 00:23:56 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:52202 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751534AbeAQFXz (ORCPT ); Wed, 17 Jan 2018 00:23:55 -0500 From: "Aneesh Kumar K.V" To: Christophe LEROY , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Scott Wood , Nicholas Piggin Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/3] powerpc/32: Fix hugepage allocation on 8xx at hint address In-Reply-To: <7341aef1-f2ac-6e9b-8279-93b0f0649b81@c-s.fr> References: <9a5dadc10f88e2fc0ac9fb5d18c5424df33f3f4c.1515169256.git.christophe.leroy@c-s.fr> <876081by7g.fsf@linux.vnet.ibm.com> <945affcd-b25c-bc6e-68e5-8bbbcd31c0fd@linux.vnet.ibm.com> <7341aef1-f2ac-6e9b-8279-93b0f0649b81@c-s.fr> Date: Wed, 17 Jan 2018 10:53:41 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-TM-AS-GCONF: 00 x-cbid: 18011705-0020-0000-0000-000003EB851D X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18011705-0021-0000-0000-0000427DBDD6 Message-Id: <87y3kxrrc2.fsf@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-01-17_02:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=1 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-1801170076 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: Christophe LEROY writes: >> >>> How should I split in separate patches ? Something like ? >>> 1/ Slice support for PPC32 > 2/ Activate slice for 8xx >> >> Yes something like that. Will you  be able to avoid that >>  if (SLICE_NUM_HIGH) from the code? That makes the code ugly. Right now >> i don't have definite suggestion on what we could do though. >> > > Could use #ifdefs instead, but in my mind it would be even more ugly. > > I would have liked just doing nothing, but the issue is that at the > moment bitmap_xxx() functions are not prepared to handle bitmaps of size > zero. Should we try to change that ? Any chance to succeed ? > How much code duplication it is to do slice_32.c? Michael, What do you suggest here? -aneesh