Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752077AbdFTKws (ORCPT ); Tue, 20 Jun 2017 06:52:48 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:41126 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751021AbdFTKwr (ORCPT ); Tue, 20 Jun 2017 06:52:47 -0400 Subject: Re: [RFC v2 02/12] powerpc: Free up four 64K PTE bits in 64K backed hpte pages. To: Ram Pai , linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org References: <1497671564-20030-1-git-send-email-linuxram@us.ibm.com> <1497671564-20030-3-git-send-email-linuxram@us.ibm.com> Cc: dave.hansen@intel.com, paulus@samba.org, aneesh.kumar@linux.vnet.ibm.com From: Anshuman Khandual Date: Tue, 20 Jun 2017 16:21:45 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <1497671564-20030-3-git-send-email-linuxram@us.ibm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable x-cbid: 17062010-0016-0000-0000-00000250F649 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17062010-0017-0000-0000-000006D083E9 Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-06-20_06:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=2 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706200196 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1139 Lines: 31 On 06/17/2017 09:22 AM, Ram Pai wrote: > Rearrange 64K PTE bits to free up bits 3, 4, 5 and 6 > in the 64K backed hpte pages. This along with the earlier > patch will entirely free up the four bits from 64K PTE. > > This patch does the following change to 64K PTE that is > backed by 64K hpte. > > H_PAGE_F_SECOND which occupied bit 4 moves to the second part > of the pte. > H_PAGE_F_GIX which occupied bit 5, 6 and 7 also moves to the > second part of the pte. > > since bit 7 is now freed up, we move H_PAGE_BUSY from bit 9 > to bit 7. Trying to minimize gaps so that contiguous bits > can be allocated if needed in the future. > > The second part of the PTE will hold > (H_PAGE_F_SECOND|H_PAGE_F_GIX) at bit 60,61,62,63. I still dont understand how we freed up the 5th bit which is used in the 5th patch. Was that bit never used for any thing on 64K page size (64K and 4K mappings) ? +#define _RPAGE_RSV5 0x00040UL +#define H_PAGE_PKEY_BIT0 _RPAGE_RSV1 +#define H_PAGE_PKEY_BIT1 _RPAGE_RSV2 +#define H_PAGE_PKEY_BIT2 _RPAGE_RSV3 +#define H_PAGE_PKEY_BIT3 _RPAGE_RSV4 +#define H_PAGE_PKEY_BIT4 _RPAGE_RSV5