[{"id":1768271,"web_url":"http://patchwork.ozlabs.org/comment/1768271/","msgid":"<20170914111825.5a8aed1e@firefly.ozlabs.ibm.com>","date":"2017-09-14T01:18:25","subject":"Re: [PATCH 3/7] powerpc: Free up four 64K PTE bits in 4K backed\n\tHPTE pages","submitter":{"id":9347,"url":"http://patchwork.ozlabs.org/api/people/9347/","name":"Balbir Singh","email":"bsingharora@gmail.com"},"content":"On Fri, 8 Sep 2017 15:44:43 -0700\nRam Pai wrote:\n\n> Rearrange 64K PTE bits to free up bits 3, 4, 5 and 6,\n> in the 4K backed HPTE pages.These bits continue to be used\n> for 64K backed HPTE pages in this patch, but will be freed\n> up in the next patch. The bit numbers are big-endian as\n> defined in the ISA3.0\n> \n> The patch does the following change to the 4k htpe backed\n> 64K PTE's format.\n> \n> H_PAGE_BUSY moves from bit 3 to bit 9 (B bit in the figure\n> \t\tbelow)\n> V0 which occupied bit 4 is not used anymore.\n> V1 which occupied bit 5 is not used anymore.\n> V2 which occupied bit 6 is not used anymore.\n> V3 which occupied bit 7 is not used anymore.\n> \n> Before the patch, the 4k backed 64k PTE format was as follows\n> \n> 0 1 2 3 4 5 6 7 8 9 10...........................63\n> : : : : : : : : : : : :\n> v v v v v v v v v v v v\n> \n> ,-,-,-,-,--,--,--,--,-,-,-,-,-,------------------,-,-,-,\n> |x|x|x|B|V0|V1|V2|V3|x| | |x|x|................|x|x|x|x| <- primary pte\n> '_'_'_'_'__'__'__'__'_'_'_'_'_'________________'_'_'_'_'\n> |S|G|I|X|S |G |I |X |S|G|I|X|..................|S|G|I|X| <- secondary pte\n> '_'_'_'_'__'__'__'__'_'_'_'_'__________________'_'_'_'_'\n> \n> After the patch, the 4k backed 64k PTE format is as follows\n> \n> 0 1 2 3 4 5 6 7 8 9 10...........................63\n> : : : : : : : : : : : :\n> v v v v v v v v v v v v\n> \n> ,-,-,-,-,--,--,--,--,-,-,-,-,-,------------------,-,-,-,\n> |x|x|x| | | | | |x|B| |x|x|................|.|.|.|.| <- primary pte\n> '_'_'_'_'__'__'__'__'_'_'_'_'_'________________'_'_'_'_'\n> |S|G|I|X|S |G |I |X |S|G|I|X|..................|S|G|I|X| <- secondary pte\n> '_'_'_'_'__'__'__'__'_'_'_'_'__________________'_'_'_'_'\n> \n> the four bits S,G,I,X (one quadruplet per 4k HPTE) that\n> cache the hash-bucket slot value, is initialized to\n> 1,1,1,1 indicating -- an invalid slot. If a HPTE gets\n> cached in a 1111 slot(i.e 7th slot of secondary hash\n> bucket), it is released immediately. In other words,\n> even though 1111 is a valid slot value in the hash\n> bucket, we consider it invalid and release the slot and\n> the HPTE. This gives us the opportunity to determine\n> the validity of S,G,I,X bits based on its contents and\n> not on any of the bits V0,V1,V2 or V3 in the primary PTE\n> \n> When we release a HPTE cached in the 1111 slot\n> we also release a legitimate slot in the primary\n> hash bucket and unmap its corresponding HPTE. This\n> is to ensure that we do get a HPTE cached in a slot\n> of the primary hash bucket, the next time we retry.\n> \n> Though treating 1111 slot as invalid, reduces the\n> number of available slots in the hash bucket and may\n> have an effect on the performance, the probabilty of\n> hitting a 1111 slot is extermely low.\n> \n> Compared to the current scheme, the above scheme\n> reduces the number of false hash table updates\n> significantly and has the added advantage of releasing\n> four valuable PTE bits for other purpose.\n> \n> NOTE:even though bits 3, 4, 5, 6, 7 are not used when\n> the 64K PTE is backed by 4k HPTE, they continue to be\n> used if the PTE gets backed by 64k HPTE. The next\n> patch will decouple that aswell, and truely release the\n> bits.\n> \n> This idea was jointly developed by Paul Mackerras,\n> Aneesh, Michael Ellermen and myself.\n> \n\nAcked-by: Balbir Singh ","headers":{"Return-Path":"","X-Original-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [103.22.144.68])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xt14s2CXfz9s7M\n\tfor ;\n\tThu, 14 Sep 2017 11:23:25 +1000 (AEST)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3xt14s0YKmzDqr8\n\tfor ;\n\tThu, 14 Sep 2017 11:23:25 +1000 (AEST)","from mail-pg0-x234.google.com (mail-pg0-x234.google.com\n\t[IPv6:2607:f8b0:400e:c05::234])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128\n\tbits)) (No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3xt0zX2g7GzDr13\n\tfor ;\n\tThu, 14 Sep 2017 11:18:48 +1000 (AEST)","by mail-pg0-x234.google.com with SMTP id i130so3578361pgc.3\n\tfor ;\n\tWed, 13 Sep 2017 18:18:48 -0700 (PDT)","from firefly.ozlabs.ibm.com ([122.99.82.10])\n\tby smtp.gmail.com with ESMTPSA id\n\tw134sm31175334pfd.186.2017.09.13.18.18.42\n\t(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);\n\tWed, 13 Sep 2017 18:18:45 -0700 (PDT)"],"Authentication-Results":["ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"r8wd80vl\"; dkim-atps=neutral","lists.ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"r8wd80vl\"; dkim-atps=neutral","ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=gmail.com\n\t(client-ip=2607:f8b0:400e:c05::234; helo=mail-pg0-x234.google.com;\n\tenvelope-from=bsingharora@gmail.com; receiver=)","lists.ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"r8wd80vl\"; dkim-atps=neutral"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=date:from:to:cc:subject:message-id:in-reply-to:references\n\t:mime-version:content-transfer-encoding;\n\tbh=g+/Nf8+T4KO7UhgH8f8IXVeCIZJL6jcDqv1rX4/DSh8=;\n\tb=r8wd80vlQYbC4QmZbid1mtLmHVteM/nHnnKul8c8mPiwLDP/GSSq7/wpfYs21/n3uN\n\tHimetMTfKj0mYiWGCQ3g0dQpsasBLJ7mCSMXQ42Y4RSVnR4hp7NGCM+3polPLsaza3kh\n\t7EBLiMo5TQYrqUpCf+wFVrqbK6Mb8LazogjcP5nJm1XL0gEzwxavADzEfY9upGMbzYsV\n\tD6zpQzDqgP5dJYHvX2WXg1sNzO31IURj2wBmHhHTgnRrSMiUPu3QoJLOnASH2QGJu52C\n\t5msJxP6RDuz1pD5UcOHsKC13hT7GrKkCDQo7TQt6lZzMBJC4VP3jvr4tKuFFNir/ctRh\n\tbNsA==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to\n\t:references:mime-version:content-transfer-encoding;\n\tbh=g+/Nf8+T4KO7UhgH8f8IXVeCIZJL6jcDqv1rX4/DSh8=;\n\tb=X1uYYCkPLJBUKkbyKSz9LhO7dik3aU+oQe2NcpSCSW/1NZMOewvNKLZ5U7SZfcRc/t\n\tZHh2dGfgodSaeO4Sgo0FmgzOg/PmL7Pve99NwTLotmBx1qLaq4OAMBelSaTIXoI1Elgb\n\t1qnlpN+3/rwjRAHnr03SxwBwrZCXOt/lUbf/Io7iIccQHhA/lKFGFGiF8bAUVTzb3AdL\n\ttosWvIUvoE+nBsB4ocaA4I7dHYuSJgALV4YTsBRKl4fuldngpvVoglZH2byMyxZelHFF\n\tM72P2HMw57EVRZ9YP3ZABDpjqdxuCipfURX+SQVPEarURFc8vyRhcvgjrvHBMVwe+oSA\n\tDKyg==","X-Gm-Message-State":"AHPjjUg4/YQIQzYm2lzNVdCMWq4zhVqPfIxBdG1vOnEYqCiQFiQ4sEvb\n\teNtvRuYjfHcSw3q5Y18=","X-Google-Smtp-Source":"ADKCNb4eqb6AfCxm4Snn9gfTFeTF3RObxeNf22+gT5lrMkngThOzSurGWfs/fQpczuopYoVW2dbnJQ==","X-Received":"by 10.98.198.70 with SMTP id m67mr19267356pfg.237.1505351926175; \n\tWed, 13 Sep 2017 18:18:46 -0700 (PDT)","Date":"Thu, 14 Sep 2017 11:18:25 +1000","From":"Balbir Singh ","To":"Ram Pai ","Subject":"Re: [PATCH 3/7] powerpc: Free up four 64K PTE bits in 4K backed\n\tHPTE pages","Message-ID":"<20170914111825.5a8aed1e@firefly.ozlabs.ibm.com>","In-Reply-To":"<1504910713-7094-4-git-send-email-linuxram@us.ibm.com>","References":"<1504910713-7094-1-git-send-email-linuxram@us.ibm.com>\n\t<1504910713-7094-4-git-send-email-linuxram@us.ibm.com>","X-Mailer":"Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-redhat-linux-gnu)","MIME-Version":"1.0","Content-Type":"text/plain; charset=US-ASCII","Content-Transfer-Encoding":"7bit","X-BeenThere":"linuxppc-dev@lists.ozlabs.org","X-Mailman-Version":"2.1.24","Precedence":"list","List-Id":"Linux on PowerPC Developers Mail List\n\t","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"ebiederm@xmission.com, mhocko@kernel.org, paulus@samba.org,\n\taneesh.kumar@linux.vnet.ibm.com, bauerman@linux.vnet.ibm.com,\n\tlinuxppc-dev@lists.ozlabs.org, khandual@linux.vnet.ibm.com","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}},{"id":1790075,"web_url":"http://patchwork.ozlabs.org/comment/1790075/","msgid":"<87o9p3kedg.fsf@concordia.ellerman.id.au>","date":"2017-10-19T03:25:47","subject":"Re: [PATCH 3/7] powerpc: Free up four 64K PTE bits in 4K backed HPTE\n\tpages","submitter":{"id":46580,"url":"http://patchwork.ozlabs.org/api/people/46580/","name":"Michael Ellerman","email":"mpe@ellerman.id.au"},"content":"Ram Pai writes:\n\n> diff --git a/arch/powerpc/mm/hash64_64k.c b/arch/powerpc/mm/hash64_64k.c\n> index 1a68cb1..c6c5559 100644\n> --- a/arch/powerpc/mm/hash64_64k.c\n> +++ b/arch/powerpc/mm/hash64_64k.c\n> @@ -126,18 +113,13 @@ int __hash_page_4K(unsigned long ea, unsigned long access, unsigned long vsid,\n> \tif (__rpte_sub_valid(rpte, subpg_index)) {\n> \t\tint ret;\n> \n> -\t\thash = hpt_hash(vpn, shift, ssize);\n> -\t\thidx = __rpte_to_hidx(rpte, subpg_index);\n> -\t\tif (hidx & _PTEIDX_SECONDARY)\n> -\t\t\thash = ~hash;\n> -\t\tslot = (hash & htab_hash_mask) * HPTES_PER_GROUP;\n> -\t\tslot += hidx & _PTEIDX_GROUP_IX;\n> +\t\tgslot = pte_get_hash_gslot(vpn, shift, ssize, rpte,\n> +\t\t\t\t\tsubpg_index);\n> +\t\tret = mmu_hash_ops.hpte_updatepp(gslot, rflags, vpn,\n> +\t\t\tMMU_PAGE_4K, MMU_PAGE_4K, ssize, flags);\n\nThis was formatted correctly before:\n \n> -\t\tret = mmu_hash_ops.hpte_updatepp(slot, rflags, vpn,\n> -\t\t\t\t\t\t MMU_PAGE_4K, MMU_PAGE_4K,\n> -\t\t\t\t\t\t ssize, flags);\n> \t\t/*\n> -\t\t *if we failed because typically the HPTE wasn't really here\n> +\t\t * if we failed because typically the HPTE wasn't really here\n\nIf you're fixing it up please make it \"If ...\".\n\n> \t\t * we try an insertion.\n> \t\t */\n> \t\tif (ret == -1)\n> @@ -148,6 +130,15 @@ int __hash_page_4K(unsigned long ea, unsigned long access, unsigned long vsid,\n> \t}\n> \n> htab_insert_hpte:\n> +\n> +\t/*\n> +\t * initialize all hidx entries to invalid value,\n> +\t * the first time the PTE is about to allocate\n> +\t * a 4K hpte\n> +\t */\n\nShould be:\n\t/*\n\t * Initialize all hidx entries to invalid value, the first time\n * the PTE is about to allocate a 4K HPTE.\n\t */\n\n> +\tif (!(old_pte & H_PAGE_COMBO))\n> +\t\trpte.hidx = ~0x0UL;\n> +\n\nPaul had the idea that if we biased the slot number by 1, we could make\nthe \"invalid\" value be == 0.\n\nThat would avoid needing to that above, and also mean the value is\ncorrectly invalid from the get-go, which would be good IMO.\n\nI think now that you've added the slot accessors it would be pretty easy\nto do.\n\n\n> \t/*\n> \t * handle H_PAGE_4K_PFN case\n> \t */\n> @@ -172,15 +163,41 @@ int __hash_page_4K(unsigned long ea, unsigned long access, unsigned long vsid,\n> \t * Primary is full, try the secondary\n> \t */\n> \tif (unlikely(slot == -1)) {\n> +\t\tbool soft_invalid;\n> +\n> \t\thpte_group = ((~hash & htab_hash_mask) * HPTES_PER_GROUP) & ~0x7UL;\n> \t\tslot = mmu_hash_ops.hpte_insert(hpte_group, vpn, pa,\n> \t\t\t\t\t\trflags, HPTE_V_SECONDARY,\n> \t\t\t\t\t\tMMU_PAGE_4K, MMU_PAGE_4K,\n> \t\t\t\t\t\tssize);\n> -\t\tif (slot == -1) {\n> -\t\t\tif (mftb() & 0x1)\n> +\n> +\t\tsoft_invalid = hpte_soft_invalid(slot);\n> +\t\tif (unlikely(soft_invalid)) {\n\n\n> +\t\t\t/*\n> +\t\t\t * we got a valid slot from a hardware point of view.\n> +\t\t\t * but we cannot use it, because we use this special\n> +\t\t\t * value; as defined by hpte_soft_invalid(),\n> +\t\t\t * to track invalid slots. We cannot use it.\n> +\t\t\t * So invalidate it.\n> +\t\t\t */\n> +\t\t\tgslot = slot & _PTEIDX_GROUP_IX;\n> +\t\t\tmmu_hash_ops.hpte_invalidate(hpte_group+gslot, vpn,\n> +\t\t\t\tMMU_PAGE_4K, MMU_PAGE_4K,\n> +\t\t\t\tssize, 0);\n\nPlease:\n\t\t\tmmu_hash_ops.hpte_invalidate(hpte_group+gslot, vpn,\n \t\t\t MMU_PAGE_4K, MMU_PAGE_4K,\n\t\t\t\t\t\t ssize, 0);\n\n> +\t\t}\n> +\n> +\t\tif (unlikely(slot == -1 || soft_invalid)) {\n> +\t\t\t/*\n> +\t\t\t * for soft invalid slot, lets ensure that we\n\nFor .. let's\n\n\ncheers","headers":{"Return-Path":"","X-Original-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3yHZ9T14PHz9t2f\n\tfor ;\n\tThu, 19 Oct 2017 14:27:09 +1100 (AEDT)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3yHZ9S6J9BzDqKs\n\tfor ;\n\tThu, 19 Oct 2017 14:27:08 +1100 (AEDT)","from ozlabs.org (bilbo.ozlabs.org [103.22.144.67])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3yHZ7w0ZW2zDqBd\n\tfor ;\n\tThu, 19 Oct 2017 14:25:48 +1100 (AEDT)","from authenticated.ozlabs.org (localhost [127.0.0.1])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPSA id 3yHZ7v4ygFz9t4c;\n\tThu, 19 Oct 2017 14:25:47 +1100 (AEDT)"],"From":"Michael Ellerman ","To":"Ram Pai , linuxppc-dev@lists.ozlabs.org","Subject":"Re: [PATCH 3/7] powerpc: Free up four 64K PTE bits in 4K backed HPTE\n\tpages","In-Reply-To":"<1504910713-7094-4-git-send-email-linuxram@us.ibm.com>","References":"<1504910713-7094-1-git-send-email-linuxram@us.ibm.com>\n\t<1504910713-7094-4-git-send-email-linuxram@us.ibm.com>","Date":"Thu, 19 Oct 2017 14:25:47 +1100","Message-ID":"<87o9p3kedg.fsf@concordia.ellerman.id.au>","MIME-Version":"1.0","Content-Type":"text/plain","X-BeenThere":"linuxppc-dev@lists.ozlabs.org","X-Mailman-Version":"2.1.24","Precedence":"list","List-Id":"Linux on PowerPC Developers Mail List\n\t","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"ebiederm@xmission.com, linuxram@us.ibm.com, mhocko@kernel.org,\n\tpaulus@samba.org, aneesh.kumar@linux.vnet.ibm.com,\n\tbauerman@linux.vnet.ibm.com, khandual@linux.vnet.ibm.com","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}},{"id":1790782,"web_url":"http://patchwork.ozlabs.org/comment/1790782/","msgid":"<20171019170211.GW5617@ram.oc3035372033.ibm.com>","date":"2017-10-19T17:02:11","subject":"Re: [PATCH 3/7] powerpc: Free up four 64K PTE bits in 4K backed HPTE\n\tpages","submitter":{"id":2667,"url":"http://patchwork.ozlabs.org/api/people/2667/","name":"Ram Pai","email":"linuxram@us.ibm.com"},"content":"On Thu, Oct 19, 2017 at 02:25:47PM +1100, Michael Ellerman wrote:\n> Ram Pai writes:\n> \n> > diff --git a/arch/powerpc/mm/hash64_64k.c b/arch/powerpc/mm/hash64_64k.c\n> > index 1a68cb1..c6c5559 100644\n> > --- a/arch/powerpc/mm/hash64_64k.c\n> > +++ b/arch/powerpc/mm/hash64_64k.c\n> > @@ -126,18 +113,13 @@ int __hash_page_4K(unsigned long ea, unsigned long access, unsigned long vsid,\n> > \tif (__rpte_sub_valid(rpte, subpg_index)) {\n> > \t\tint ret;\n> > \n> > -\t\thash = hpt_hash(vpn, shift, ssize);\n> > -\t\thidx = __rpte_to_hidx(rpte, subpg_index);\n> > -\t\tif (hidx & _PTEIDX_SECONDARY)\n> > -\t\t\thash = ~hash;\n> > -\t\tslot = (hash & htab_hash_mask) * HPTES_PER_GROUP;\n> > -\t\tslot += hidx & _PTEIDX_GROUP_IX;\n> > +\t\tgslot = pte_get_hash_gslot(vpn, shift, ssize, rpte,\n> > +\t\t\t\t\tsubpg_index);\n> > +\t\tret = mmu_hash_ops.hpte_updatepp(gslot, rflags, vpn,\n> > +\t\t\tMMU_PAGE_4K, MMU_PAGE_4K, ssize, flags);\n> \n> This was formatted correctly before:\n> \n> > -\t\tret = mmu_hash_ops.hpte_updatepp(slot, rflags, vpn,\n> > -\t\t\t\t\t\t MMU_PAGE_4K, MMU_PAGE_4K,\n> > -\t\t\t\t\t\t ssize, flags);\n> > \t\t/*\n> > -\t\t *if we failed because typically the HPTE wasn't really here\n> > +\t\t * if we failed because typically the HPTE wasn't really here\n> \n> If you're fixing it up please make it \"If ...\".\n> \n> > \t\t * we try an insertion.\n> > \t\t */\n> > \t\tif (ret == -1)\n> > @@ -148,6 +130,15 @@ int __hash_page_4K(unsigned long ea, unsigned long access, unsigned long vsid,\n> > \t}\n> > \n> > htab_insert_hpte:\n> > +\n> > +\t/*\n> > +\t * initialize all hidx entries to invalid value,\n> > +\t * the first time the PTE is about to allocate\n> > +\t * a 4K hpte\n> > +\t */\n> \n> Should be:\n> \t/*\n> \t * Initialize all hidx entries to invalid value, the first time\n> * the PTE is about to allocate a 4K HPTE.\n> \t */\n> \n> > +\tif (!(old_pte & H_PAGE_COMBO))\n> > +\t\trpte.hidx = ~0x0UL;\n> > +\n> \n> Paul had the idea that if we biased the slot number by 1, we could make\n> the \"invalid\" value be == 0.\n> \n> That would avoid needing to that above, and also mean the value is\n> correctly invalid from the get-go, which would be good IMO.\n> \n> I think now that you've added the slot accessors it would be pretty easy\n> to do.\n\nI did attempt to do so, and was not getting it right. The machine went\nunstable. So left it with an accessor, to be revisited at a\nlater point in time. That time has come... I suppose. Shall I make it a\nseparate patch instead of baking it into this patch?\n\nRP","headers":{"Return-Path":"","X-Original-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3yHwL038SMz9tX4\n\tfor ;\n\tFri, 20 Oct 2017 04:05:44 +1100 (AEDT)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3yHwL02FTBzDqF3\n\tfor ;\n\tFri, 20 Oct 2017 04:05:44 +1100 (AEDT)","from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com\n\t[148.163.156.1])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3yHwG66Fw5zDqFH\n\tfor ;\n\tFri, 20 Oct 2017 04:02:22 +1100 (AEDT)","from pps.filterd (m0098404.ppops.net [127.0.0.1])\n\tby mx0a-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id\n\tv9JH1pwr019278\n\tfor ; Thu, 19 Oct 2017 13:02:20 -0400","from e15.ny.us.ibm.com (e15.ny.us.ibm.com [129.33.205.205])\n\tby mx0a-001b2d01.pphosted.com with ESMTP id 2dpvu3pdjt-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor ; Thu, 19 Oct 2017 13:02:20 -0400","from localhost\n\tby e15.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use\n\tOnly! Violators will be prosecuted\n\tfor from ;\n\tThu, 19 Oct 2017 13:02:18 -0400","from b01cxnp22033.gho.pok.ibm.com (9.57.198.23)\n\tby e15.ny.us.ibm.com (146.89.104.202) with IBM ESMTP SMTP Gateway:\n\tAuthorized Use Only! Violators will be prosecuted; \n\tThu, 19 Oct 2017 13:02:15 -0400","from b01ledav005.gho.pok.ibm.com (b01ledav005.gho.pok.ibm.com\n\t[9.57.199.110])\n\tby b01cxnp22033.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP\n\tid v9JH2FKK41353438; Thu, 19 Oct 2017 17:02:15 GMT","from b01ledav005.gho.pok.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id D6919AE04E;\n\tThu, 19 Oct 2017 13:02:56 -0400 (EDT)","from ram.oc3035372033.ibm.com (unknown [9.85.176.245])\n\tby b01ledav005.gho.pok.ibm.com (Postfix) with ESMTPS id B197EAE034;\n\tThu, 19 Oct 2017 13:02:55 -0400 (EDT)"],"Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=us.ibm.com\n\t(client-ip=148.163.156.1; helo=mx0a-001b2d01.pphosted.com;\n\tenvelope-from=linuxram@us.ibm.com; receiver=)","Date":"Thu, 19 Oct 2017 10:02:11 -0700","From":"Ram Pai ","To":"Michael Ellerman ","Subject":"Re: [PATCH 3/7] powerpc: Free up four 64K PTE bits in 4K backed HPTE\n\tpages","References":"<1504910713-7094-1-git-send-email-linuxram@us.ibm.com>\n\t<1504910713-7094-4-git-send-email-linuxram@us.ibm.com>\n\t<87o9p3kedg.fsf@concordia.ellerman.id.au>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<87o9p3kedg.fsf@concordia.ellerman.id.au>","User-Agent":"Mutt/1.5.20 (2009-12-10)","X-TM-AS-GCONF":"00","x-cbid":"17101917-0036-0000-0000-0000027E5582","X-IBM-SpamModules-Scores":"","X-IBM-SpamModules-Versions":"BY=3.00007919; HX=3.00000241; KW=3.00000007;\n\tPH=3.00000004; SC=3.00000238; SDB=6.00933460; UDB=6.00470172;\n\tIPR=6.00713748; \n\tBA=6.00005651; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009;\n\tZB=6.00000000; \n\tZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00017609;\n\tXFM=3.00000015; UTC=2017-10-19 17:02:18","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"17101917-0037-0000-0000-000042211027","Message-Id":"<20171019170211.GW5617@ram.oc3035372033.ibm.com>","X-Proofpoint-Virus-Version":"vendor=fsecure engine=2.50.10432:, ,\n\tdefinitions=2017-10-19_08:, , signatures=0","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n\tspamscore=0 suspectscore=0\n\tmalwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam\n\tadjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000\n\tdefinitions=main-1710190235","X-BeenThere":"linuxppc-dev@lists.ozlabs.org","X-Mailman-Version":"2.1.24","Precedence":"list","List-Id":"Linux on PowerPC Developers Mail List\n\t","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Reply-To":"Ram Pai ","Cc":"ebiederm@xmission.com, mhocko@kernel.org, paulus@samba.org,\n\taneesh.kumar@linux.vnet.ibm.com, bauerman@linux.vnet.ibm.com,\n\tlinuxppc-dev@lists.ozlabs.org, khandual@linux.vnet.ibm.com","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}},{"id":1792488,"web_url":"http://patchwork.ozlabs.org/comment/1792488/","msgid":"<871slu9ro4.fsf@linux.vnet.ibm.com>","date":"2017-10-23T08:47:39","subject":"Re: [PATCH 3/7] powerpc: Free up four 64K PTE bits in 4K backed HPTE\n\tpages","submitter":{"id":664,"url":"http://patchwork.ozlabs.org/api/people/664/","name":"Aneesh Kumar K.V","email":"aneesh.kumar@linux.vnet.ibm.com"},"content":"Michael Ellerman writes:\n\n> Ram Pai writes:\n>\n>> diff --git a/arch/powerpc/mm/hash64_64k.c b/arch/powerpc/mm/hash64_64k.c\n>> index 1a68cb1..c6c5559 100644\n>> --- a/arch/powerpc/mm/hash64_64k.c\n>> +++ b/arch/powerpc/mm/hash64_64k.c\n>> @@ -126,18 +113,13 @@ int __hash_page_4K(unsigned long ea, unsigned long access, unsigned long vsid,\n>> \tif (__rpte_sub_valid(rpte, subpg_index)) {\n>> \t\tint ret;\n>> \n>> -\t\thash = hpt_hash(vpn, shift, ssize);\n>> -\t\thidx = __rpte_to_hidx(rpte, subpg_index);\n>> -\t\tif (hidx & _PTEIDX_SECONDARY)\n>> -\t\t\thash = ~hash;\n>> -\t\tslot = (hash & htab_hash_mask) * HPTES_PER_GROUP;\n>> -\t\tslot += hidx & _PTEIDX_GROUP_IX;\n>> +\t\tgslot = pte_get_hash_gslot(vpn, shift, ssize, rpte,\n>> +\t\t\t\t\tsubpg_index);\n>> +\t\tret = mmu_hash_ops.hpte_updatepp(gslot, rflags, vpn,\n>> +\t\t\tMMU_PAGE_4K, MMU_PAGE_4K, ssize, flags);\n>\n> This was formatted correctly before:\n> \n>> -\t\tret = mmu_hash_ops.hpte_updatepp(slot, rflags, vpn,\n>> -\t\t\t\t\t\t MMU_PAGE_4K, MMU_PAGE_4K,\n>> -\t\t\t\t\t\t ssize, flags);\n>> \t\t/*\n>> -\t\t *if we failed because typically the HPTE wasn't really here\n>> +\t\t * if we failed because typically the HPTE wasn't really here\n>\n> If you're fixing it up please make it \"If ...\".\n>\n>> \t\t * we try an insertion.\n>> \t\t */\n>> \t\tif (ret == -1)\n>> @@ -148,6 +130,15 @@ int __hash_page_4K(unsigned long ea, unsigned long access, unsigned long vsid,\n>> \t}\n>> \n>> htab_insert_hpte:\n>> +\n>> +\t/*\n>> +\t * initialize all hidx entries to invalid value,\n>> +\t * the first time the PTE is about to allocate\n>> +\t * a 4K hpte\n>> +\t */\n>\n> Should be:\n> \t/*\n> \t * Initialize all hidx entries to invalid value, the first time\n> * the PTE is about to allocate a 4K HPTE.\n> \t */\n>\n>> +\tif (!(old_pte & H_PAGE_COMBO))\n>> +\t\trpte.hidx = ~0x0UL;\n>> +\n>\n> Paul had the idea that if we biased the slot number by 1, we could make\n> the \"invalid\" value be == 0.\n>\n> That would avoid needing to that above, and also mean the value is\n> correctly invalid from the get-go, which would be good IMO.\n>\n> I think now that you've added the slot accessors it would be pretty easy\n> to do.\n\nThat would be imply, we loose one slot in primary group, which means we\nwill do extra work in some case because our primary now has only 7\nslots. And in case of pseries, the hypervisor will always return the\nleast available slot, which implie we will do extra hcalls in case of an\nhpte insert to an empty group?\n\n-aneesh","headers":{"Return-Path":"","X-Original-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3yLCvK5DGwz9t6F\n\tfor ;\n\tMon, 23 Oct 2017 21:54:05 +1100 (AEDT)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3yLCvK4GCFzDrLc\n\tfor ;\n\tMon, 23 Oct 2017 21:54:05 +1100 (AEDT)","from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com\n\t[148.163.156.1])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3yLCmD0kxnzDqyr\n\tfor ;\n\tMon, 23 Oct 2017 21:47:55 +1100 (AEDT)","from pps.filterd (m0098393.ppops.net [127.0.0.1])\n\tby mx0a-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id\n\tv9NAl9tS055990\n\tfor ; Mon, 23 Oct 2017 06:47:52 -0400","from e06smtp14.uk.ibm.com (e06smtp14.uk.ibm.com [195.75.94.110])\n\tby mx0a-001b2d01.pphosted.com with ESMTP id 2dse3ttde8-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor ; Mon, 23 Oct 2017 06:47:52 -0400","from localhost\n\tby e06smtp14.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use\n\tOnly! Violators will be prosecuted\n\tfor from\n\t; Mon, 23 Oct 2017 11:47:50 +0100","from b06cxnps3074.portsmouth.uk.ibm.com (9.149.109.194)\n\tby e06smtp14.uk.ibm.com (192.168.101.144) with IBM ESMTP SMTP\n\tGateway: Authorized Use Only! Violators will be prosecuted; \n\tMon, 23 Oct 2017 11:47:47 +0100","from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97])\n\tby b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with\n\tESMTP id v9NAljUD24772756\n\tfor ; Mon, 23 Oct 2017 10:47:47 GMT","from d23av03.au.ibm.com (localhost [127.0.0.1])\n\tby d23av03.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id\n\tv9NAlcZx009174\n\tfor ; Mon, 23 Oct 2017 21:47:39 +1100","from skywalker ([9.85.198.75])\n\tby d23av03.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with SMTP id\n\tv9NAlTNm009041; Mon, 23 Oct 2017 21:47:32 +1100","(nullmailer pid 6941 invoked by uid 1000);\n\tMon, 23 Oct 2017 08:47:39 -0000"],"Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=linux.vnet.ibm.com\n\t(client-ip=148.163.156.1; helo=mx0a-001b2d01.pphosted.com;\n\tenvelope-from=aneesh.kumar@linux.vnet.ibm.com; receiver=)","From":"\"Aneesh Kumar K.V\" ","To":"Michael Ellerman , Ram Pai ,\n\tlinuxppc-dev@lists.ozlabs.org","Subject":"Re: [PATCH 3/7] powerpc: Free up four 64K PTE bits in 4K backed HPTE\n\tpages","In-Reply-To":"<87o9p3kedg.fsf@concordia.ellerman.id.au>","References":"<1504910713-7094-1-git-send-email-linuxram@us.ibm.com>\n\t<1504910713-7094-4-git-send-email-linuxram@us.ibm.com>\n\t<87o9p3kedg.fsf@concordia.ellerman.id.au>","Date":"Mon, 23 Oct 2017 14:17:39 +0530","MIME-Version":"1.0","Content-Type":"text/plain","X-TM-AS-MML":"disable","x-cbid":"17102310-0016-0000-0000-000004F8DED4","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"17102310-0017-0000-0000-000028344B5D","Message-Id":"<871slu9ro4.fsf@linux.vnet.ibm.com>","X-Proofpoint-Virus-Version":"vendor=fsecure engine=2.50.10432:, ,\n\tdefinitions=2017-10-23_03:, , signatures=0","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n\tspamscore=0 suspectscore=1\n\tmalwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam\n\tadjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000\n\tdefinitions=main-1710230155","X-BeenThere":"linuxppc-dev@lists.ozlabs.org","X-Mailman-Version":"2.1.24","Precedence":"list","List-Id":"Linux on PowerPC Developers Mail List\n\t","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"linuxram@us.ibm.com, mhocko@kernel.org, paulus@samba.org,\n\tebiederm@xmission.com, bauerman@linux.vnet.ibm.com,\n\tkhandual@linux.vnet.ibm.com","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}},{"id":1792667,"web_url":"http://patchwork.ozlabs.org/comment/1792667/","msgid":"<20171023162934.GA5454@ram.oc3035372033.ibm.com>","date":"2017-10-23T16:29:34","subject":"Re: [PATCH 3/7] powerpc: Free up four 64K PTE bits in 4K backed HPTE\n\tpages","submitter":{"id":2667,"url":"http://patchwork.ozlabs.org/api/people/2667/","name":"Ram Pai","email":"linuxram@us.ibm.com"},"content":"On Mon, Oct 23, 2017 at 02:17:39PM +0530, Aneesh Kumar K.V wrote:\n> Michael Ellerman writes:\n> \n> > Ram Pai writes:\n> >\n> >> diff --git a/arch/powerpc/mm/hash64_64k.c b/arch/powerpc/mm/hash64_64k.c\n> >> index 1a68cb1..c6c5559 100644\n> >> --- a/arch/powerpc/mm/hash64_64k.c\n> >> +++ b/arch/powerpc/mm/hash64_64k.c\n> >> @@ -126,18 +113,13 @@ int __hash_page_4K(unsigned long ea, unsigned long access, unsigned long vsid,\n> >> \tif (__rpte_sub_valid(rpte, subpg_index)) {\n> >> \t\tint ret;\n> >> \n> >> -\t\thash = hpt_hash(vpn, shift, ssize);\n> >> -\t\thidx = __rpte_to_hidx(rpte, subpg_index);\n> >> -\t\tif (hidx & _PTEIDX_SECONDARY)\n> >> -\t\t\thash = ~hash;\n> >> -\t\tslot = (hash & htab_hash_mask) * HPTES_PER_GROUP;\n> >> -\t\tslot += hidx & _PTEIDX_GROUP_IX;\n> >> +\t\tgslot = pte_get_hash_gslot(vpn, shift, ssize, rpte,\n> >> +\t\t\t\t\tsubpg_index);\n> >> +\t\tret = mmu_hash_ops.hpte_updatepp(gslot, rflags, vpn,\n> >> +\t\t\tMMU_PAGE_4K, MMU_PAGE_4K, ssize, flags);\n> >\n> > This was formatted correctly before:\n> > \n> >> -\t\tret = mmu_hash_ops.hpte_updatepp(slot, rflags, vpn,\n> >> -\t\t\t\t\t\t MMU_PAGE_4K, MMU_PAGE_4K,\n> >> -\t\t\t\t\t\t ssize, flags);\n> >> \t\t/*\n> >> -\t\t *if we failed because typically the HPTE wasn't really here\n> >> +\t\t * if we failed because typically the HPTE wasn't really here\n> >\n> > If you're fixing it up please make it \"If ...\".\n> >\n> >> \t\t * we try an insertion.\n> >> \t\t */\n> >> \t\tif (ret == -1)\n> >> @@ -148,6 +130,15 @@ int __hash_page_4K(unsigned long ea, unsigned long access, unsigned long vsid,\n> >> \t}\n> >> \n> >> htab_insert_hpte:\n> >> +\n> >> +\t/*\n> >> +\t * initialize all hidx entries to invalid value,\n> >> +\t * the first time the PTE is about to allocate\n> >> +\t * a 4K hpte\n> >> +\t */\n> >\n> > Should be:\n> > \t/*\n> > \t * Initialize all hidx entries to invalid value, the first time\n> > * the PTE is about to allocate a 4K HPTE.\n> > \t */\n> >\n> >> +\tif (!(old_pte & H_PAGE_COMBO))\n> >> +\t\trpte.hidx = ~0x0UL;\n> >> +\n> >\n> > Paul had the idea that if we biased the slot number by 1, we could make\n> > the \"invalid\" value be == 0.\n> >\n> > That would avoid needing to that above, and also mean the value is\n> > correctly invalid from the get-go, which would be good IMO.\n> >\n> > I think now that you've added the slot accessors it would be pretty easy\n> > to do.\n> \n> That would be imply, we loose one slot in primary group, which means we\n> will do extra work in some case because our primary now has only 7\n> slots. And in case of pseries, the hypervisor will always return the\n> least available slot, which implie we will do extra hcalls in case of an\n> hpte insert to an empty group?\n\n\nNo. that is not the idea. The idea is that slot 'F' in the seconday\nwill continue to be a invalid slot, but will be represented as\noffset-by-one in the PTE. In other words, 0 will be repesented as 1,\n1 as 2.... and n as (n+1)%32\n\nThe idea seems feasible. It has the advantage -- where 0 in the PTE\nmeans invalid slot. But it can be confusing to the casual code-\nreader. Will need to put in a big-huge comment to explain that.\n\nRP","headers":{"Return-Path":"","X-Original-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3yLMNh2VHWz9t5s\n\tfor ;\n\tTue, 24 Oct 2017 03:31:32 +1100 (AEDT)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3yLMNg6lCpzDqhg\n\tfor ;\n\tTue, 24 Oct 2017 03:31:31 +1100 (AEDT)","from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com\n\t[148.163.158.5])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3yLMLg0gBZzDqhf\n\tfor ;\n\tTue, 24 Oct 2017 03:29:46 +1100 (AEDT)","from pps.filterd (m0098420.ppops.net [127.0.0.1])\n\tby mx0b-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id\n\tv9NGOJap120926\n\tfor ; Mon, 23 Oct 2017 12:29:44 -0400","from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.152])\n\tby mx0b-001b2d01.pphosted.com with ESMTP id 2dsjcfvt4j-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor ; Mon, 23 Oct 2017 12:29:44 -0400","from localhost\n\tby e34.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use\n\tOnly! Violators will be prosecuted\n\tfor from ;\n\tMon, 23 Oct 2017 10:29:43 -0600","from b03cxnp08028.gho.boulder.ibm.com (9.17.130.20)\n\tby e34.co.us.ibm.com (192.168.1.134) with IBM ESMTP SMTP Gateway:\n\tAuthorized Use Only! Violators will be prosecuted; \n\tMon, 23 Oct 2017 10:29:40 -0600","from b03ledav003.gho.boulder.ibm.com\n\t(b03ledav003.gho.boulder.ibm.com [9.17.130.234])\n\tby b03cxnp08028.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with\n\tESMTP id v9NGTddM31654134; Mon, 23 Oct 2017 09:29:39 -0700","from b03ledav003.gho.boulder.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id 309C06A03B;\n\tMon, 23 Oct 2017 10:29:40 -0600 (MDT)","from ram.oc3035372033.ibm.com (unknown [9.80.225.235])\n\tby b03ledav003.gho.boulder.ibm.com (Postfix) with ESMTPS id\n\t15DA76A041; Mon, 23 Oct 2017 10:29:37 -0600 (MDT)"],"Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=us.ibm.com\n\t(client-ip=148.163.158.5; helo=mx0a-001b2d01.pphosted.com;\n\tenvelope-from=linuxram@us.ibm.com; receiver=)","Date":"Mon, 23 Oct 2017 09:29:34 -0700","From":"Ram Pai ","To":"\"Aneesh Kumar K.V\" ","Subject":"Re: [PATCH 3/7] powerpc: Free up four 64K PTE bits in 4K backed HPTE\n\tpages","References":"<1504910713-7094-1-git-send-email-linuxram@us.ibm.com>\n\t<1504910713-7094-4-git-send-email-linuxram@us.ibm.com>\n\t<87o9p3kedg.fsf@concordia.ellerman.id.au>\n\t<871slu9ro4.fsf@linux.vnet.ibm.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<871slu9ro4.fsf@linux.vnet.ibm.com>","User-Agent":"Mutt/1.5.20 (2009-12-10)","X-TM-AS-GCONF":"00","x-cbid":"17102316-0016-0000-0000-000007B268B9","X-IBM-SpamModules-Scores":"","X-IBM-SpamModules-Versions":"BY=3.00007940; HX=3.00000241; KW=3.00000007;\n\tPH=3.00000004; SC=3.00000239; SDB=6.00935361; UDB=6.00471244;\n\tIPR=6.00715627; \n\tBA=6.00005656; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009;\n\tZB=6.00000000; \n\tZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00017672;\n\tXFM=3.00000015; UTC=2017-10-23 16:29:42","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"17102316-0017-0000-0000-00003BF89A7B","Message-Id":"<20171023162934.GA5454@ram.oc3035372033.ibm.com>","X-Proofpoint-Virus-Version":"vendor=fsecure engine=2.50.10432:, ,\n\tdefinitions=2017-10-23_07:, , signatures=0","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n\tspamscore=0 suspectscore=0\n\tmalwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam\n\tadjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000\n\tdefinitions=main-1710230231","X-BeenThere":"linuxppc-dev@lists.ozlabs.org","X-Mailman-Version":"2.1.24","Precedence":"list","List-Id":"Linux on PowerPC Developers Mail List\n\t","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Reply-To":"Ram Pai ","Cc":"mhocko@kernel.org, paulus@samba.org, ebiederm@xmission.com,\n\tbauerman@linux.vnet.ibm.com, linuxppc-dev@lists.ozlabs.org,\n\tkhandual@linux.vnet.ibm.com","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}},{"id":1793656,"web_url":"http://patchwork.ozlabs.org/comment/1793656/","msgid":"<87d15b1t6u.fsf@concordia.ellerman.id.au>","date":"2017-10-25T09:18:49","subject":"Re: [PATCH 3/7] powerpc: Free up four 64K PTE bits in 4K backed HPTE\n\tpages","submitter":{"id":46580,"url":"http://patchwork.ozlabs.org/api/people/46580/","name":"Michael Ellerman","email":"mpe@ellerman.id.au"},"content":"Ram Pai writes:\n> On Mon, Oct 23, 2017 at 02:17:39PM +0530, Aneesh Kumar K.V wrote:\n>> Michael Ellerman writes:\n>> > Ram Pai writes:\n...\n>> > Should be:\n>> > \t/*\n>> > \t * Initialize all hidx entries to invalid value, the first time\n>> > * the PTE is about to allocate a 4K HPTE.\n>> > \t */\n>> >\n>> >> +\tif (!(old_pte & H_PAGE_COMBO))\n>> >> +\t\trpte.hidx = ~0x0UL;\n>> >> +\n>> >\n>> > Paul had the idea that if we biased the slot number by 1, we could make\n>> > the \"invalid\" value be == 0.\n>> >\n>> > That would avoid needing to that above, and also mean the value is\n>> > correctly invalid from the get-go, which would be good IMO.\n>> >\n>> > I think now that you've added the slot accessors it would be pretty easy\n>> > to do.\n>> \n>> That would be imply, we loose one slot in primary group, which means we\n>> will do extra work in some case because our primary now has only 7\n>> slots. And in case of pseries, the hypervisor will always return the\n>> least available slot, which implie we will do extra hcalls in case of an\n>> hpte insert to an empty group?\n>\n> No. that is not the idea. The idea is that slot 'F' in the seconday\n> will continue to be a invalid slot, but will be represented as\n> offset-by-one in the PTE. In other words, 0 will be repesented as 1,\n> 1 as 2.... and n as (n+1)%32\n\nRight.\n\n> The idea seems feasible. It has the advantage -- where 0 in the PTE\n> means invalid slot. But it can be confusing to the casual code-\n> reader. Will need to put in a big-huge comment to explain that.\n\nThis code is already confusing to *any* reader, so I don't think it's a\nworry. :)\n\ncheers","headers":{"Return-Path":"","X-Original-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [103.22.144.68])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3yMPk32hbJz9s8J\n\tfor ;\n\tWed, 25 Oct 2017 20:20:11 +1100 (AEDT)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3yMPk30TPCzDr16\n\tfor ;\n\tWed, 25 Oct 2017 20:20:11 +1100 (AEDT)","from ozlabs.org (ozlabs.org [IPv6:2401:3900:2:1::2])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3yMPhf1g0zzDqkp\n\tfor ;\n\tWed, 25 Oct 2017 20:18:58 +1100 (AEDT)","from authenticated.ozlabs.org (localhost [127.0.0.1])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPSA id 3yMPhc06tVz9s8J;\n\tWed, 25 Oct 2017 20:18:55 +1100 (AEDT)"],"From":"Michael Ellerman ","To":"Ram Pai ,\n\t\"Aneesh Kumar K.V\" ","Subject":"Re: [PATCH 3/7] powerpc: Free up four 64K PTE bits in 4K backed HPTE\n\tpages","In-Reply-To":"<20171023162934.GA5454@ram.oc3035372033.ibm.com>","References":"<1504910713-7094-1-git-send-email-linuxram@us.ibm.com>\n\t<1504910713-7094-4-git-send-email-linuxram@us.ibm.com>\n\t<87o9p3kedg.fsf@concordia.ellerman.id.au>\n\t<871slu9ro4.fsf@linux.vnet.ibm.com>\n\t<20171023162934.GA5454@ram.oc3035372033.ibm.com>","Date":"Wed, 25 Oct 2017 11:18:49 +0200","Message-ID":"<87d15b1t6u.fsf@concordia.ellerman.id.au>","MIME-Version":"1.0","Content-Type":"text/plain","X-BeenThere":"linuxppc-dev@lists.ozlabs.org","X-Mailman-Version":"2.1.24","Precedence":"list","List-Id":"Linux on PowerPC Developers Mail List\n\t","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"mhocko@kernel.org, paulus@samba.org, ebiederm@xmission.com,\n\tbauerman@linux.vnet.ibm.com, linuxppc-dev@lists.ozlabs.org,\n\tkhandual@linux.vnet.ibm.com","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}},{"id":1794033,"web_url":"http://patchwork.ozlabs.org/comment/1794033/","msgid":"<20171026060826.GB5485@ram.oc3035372033.ibm.com>","date":"2017-10-26T06:08:26","subject":"Re: [PATCH 3/7] powerpc: Free up four 64K PTE bits in 4K backed HPTE\n\tpages","submitter":{"id":2667,"url":"http://patchwork.ozlabs.org/api/people/2667/","name":"Ram Pai","email":"linuxram@us.ibm.com"},"content":"On Wed, Oct 25, 2017 at 11:18:49AM +0200, Michael Ellerman wrote:\n> Ram Pai writes:\n> > On Mon, Oct 23, 2017 at 02:17:39PM +0530, Aneesh Kumar K.V wrote:\n> >> Michael Ellerman writes:\n> >> > Ram Pai writes:\n> ...\n> >> > Should be:\n> >> > \t/*\n> >> > \t * Initialize all hidx entries to invalid value, the first time\n> >> > * the PTE is about to allocate a 4K HPTE.\n> >> > \t */\n> >> >\n> >> >> +\tif (!(old_pte & H_PAGE_COMBO))\n> >> >> +\t\trpte.hidx = ~0x0UL;\n> >> >> +\n> >> >\n> >> > Paul had the idea that if we biased the slot number by 1, we could make\n> >> > the \"invalid\" value be == 0.\n> >> >\n> >> > That would avoid needing to that above, and also mean the value is\n> >> > correctly invalid from the get-go, which would be good IMO.\n> >> >\n> >> > I think now that you've added the slot accessors it would be pretty easy\n> >> > to do.\n> >> \n> >> That would be imply, we loose one slot in primary group, which means we\n> >> will do extra work in some case because our primary now has only 7\n> >> slots. And in case of pseries, the hypervisor will always return the\n> >> least available slot, which implie we will do extra hcalls in case of an\n> >> hpte insert to an empty group?\n> >\n> > No. that is not the idea. The idea is that slot 'F' in the seconday\n> > will continue to be a invalid slot, but will be represented as\n> > offset-by-one in the PTE. In other words, 0 will be repesented as 1,\n> > 1 as 2.... and n as (n+1)%32\n> \n> Right.\n> \n> > The idea seems feasible. It has the advantage -- where 0 in the PTE\n> > means invalid slot. But it can be confusing to the casual code-\n> > reader. Will need to put in a big-huge comment to explain that.\n> \n> This code is already confusing to *any* reader, so I don't think it's a\n> worry. :)\n\nI just got it coded and working. But I see no advantage implementing\nthe shifted-value. The hidx in the secondary-part of the pte, still\nneeds to be initialzed to all-zeros. Because it could contain the value of\nthe hidx corresponding the 64k-backed hpte, which needs to be cleared.\n\nI will send the patch anyway. But we should not apply it\nfor I see no apparent gain.\n\nRP\n\n> \n> cheers","headers":{"Return-Path":"","X-Original-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [103.22.144.68])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3yMxS45gyQz9t3H\n\tfor ;\n\tThu, 26 Oct 2017 17:09:56 +1100 (AEDT)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3yMxS44cd0zDr4V\n\tfor ;\n\tThu, 26 Oct 2017 17:09:56 +1100 (AEDT)","from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com\n\t[148.163.156.1])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3yMxQb4MB2zDqT0\n\tfor ;\n\tThu, 26 Oct 2017 17:08:38 +1100 (AEDT)","from pps.filterd (m0098393.ppops.net [127.0.0.1])\n\tby mx0a-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id\n\tv9Q64mo6044995\n\tfor ; Thu, 26 Oct 2017 02:08:36 -0400","from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.149])\n\tby mx0a-001b2d01.pphosted.com with ESMTP id 2du49xe4jk-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor ; Thu, 26 Oct 2017 02:08:35 -0400","from localhost\n\tby e31.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use\n\tOnly! Violators will be prosecuted\n\tfor from ;\n\tThu, 26 Oct 2017 00:08:34 -0600","from b03cxnp07029.gho.boulder.ibm.com (9.17.130.16)\n\tby e31.co.us.ibm.com (192.168.1.131) with IBM ESMTP SMTP Gateway:\n\tAuthorized Use Only! Violators will be prosecuted; \n\tThu, 26 Oct 2017 00:08:31 -0600","from b03ledav005.gho.boulder.ibm.com\n\t(b03ledav005.gho.boulder.ibm.com [9.17.130.236])\n\tby b03cxnp07029.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with\n\tESMTP id v9Q68U4u7864762; Wed, 25 Oct 2017 23:08:30 -0700","from b03ledav005.gho.boulder.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id C5403BE038;\n\tThu, 26 Oct 2017 00:08:30 -0600 (MDT)","from ram.oc3035372033.ibm.com (unknown [9.85.185.157])\n\tby b03ledav005.gho.boulder.ibm.com (Postfix) with ESMTPS id\n\t05C4BBE03B; Thu, 26 Oct 2017 00:08:28 -0600 (MDT)"],"Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=us.ibm.com\n\t(client-ip=148.163.156.1; helo=mx0a-001b2d01.pphosted.com;\n\tenvelope-from=linuxram@us.ibm.com; receiver=)","Date":"Wed, 25 Oct 2017 23:08:26 -0700","From":"Ram Pai ","To":"Michael Ellerman ","Subject":"Re: [PATCH 3/7] powerpc: Free up four 64K PTE bits in 4K backed HPTE\n\tpages","References":"<1504910713-7094-1-git-send-email-linuxram@us.ibm.com>\n\t<1504910713-7094-4-git-send-email-linuxram@us.ibm.com>\n\t<87o9p3kedg.fsf@concordia.ellerman.id.au>\n\t<871slu9ro4.fsf@linux.vnet.ibm.com>\n\t<20171023162934.GA5454@ram.oc3035372033.ibm.com>\n\t<87d15b1t6u.fsf@concordia.ellerman.id.au>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<87d15b1t6u.fsf@concordia.ellerman.id.au>","User-Agent":"Mutt/1.5.20 (2009-12-10)","X-TM-AS-GCONF":"00","x-cbid":"17102606-8235-0000-0000-00000C77E5B8","X-IBM-SpamModules-Scores":"","X-IBM-SpamModules-Versions":"BY=3.00007952; HX=3.00000241; KW=3.00000007;\n\tPH=3.00000004; SC=3.00000239; SDB=6.00936594; UDB=6.00471981;\n\tIPR=6.00716857; \n\tBA=6.00005660; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009;\n\tZB=6.00000000; \n\tZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00017719;\n\tXFM=3.00000015; UTC=2017-10-26 06:08:33","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"17102606-8236-0000-0000-00003E318052","Message-Id":"<20171026060826.GB5485@ram.oc3035372033.ibm.com>","X-Proofpoint-Virus-Version":"vendor=fsecure engine=2.50.10432:, ,\n\tdefinitions=2017-10-26_01:, , signatures=0","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n\tpriorityscore=1501\n\tmalwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0\n\tclxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0\n\tclassifier=spam adjust=0 reason=mlx scancount=1\n\tengine=8.0.1-1707230000\n\tdefinitions=main-1710260085","X-BeenThere":"linuxppc-dev@lists.ozlabs.org","X-Mailman-Version":"2.1.24","Precedence":"list","List-Id":"Linux on PowerPC Developers Mail List\n\t","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Reply-To":"Ram Pai ","Cc":"ebiederm@xmission.com, mhocko@kernel.org, paulus@samba.org,\n\t\"Aneesh Kumar K.V\" ,\n\tbauerman@linux.vnet.ibm.com, linuxppc-dev@lists.ozlabs.org,\n\tkhandual@linux.vnet.ibm.com","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}}]