Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH 09/18] ARC: mm: non-functional code cleanup ahead of 3
 levels
To:     Mike Rapoport <rppt@kernel.org>
Cc:     linux-snps-arc@lists.infradead.org, linux-kernel@vger.kernel.org,
        linux-mm@kvack.org, Anshuman Khandual <anshuman.khandual@arm.com>
References: <20210811004258.138075-1-vgupta@kernel.org>
 <20210811004258.138075-10-vgupta@kernel.org> <YRPDL90Qr5RLDmnT@kernel.org>
From:   Vineet Gupta <vgupta@kernel.org>
Message-ID: <7d022d55-c70b-b3ac-4f0b-1faa26c0d4bd@kernel.org>
Date:   Wed, 11 Aug 2021 18:37:19 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <YRPDL90Qr5RLDmnT@kernel.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Precedence: bulk

On 8/11/21 5:31 AM, Mike Rapoport wrote:
>> +/*
>> + * For ARC, pgtable_t is not struct page *, but pte_t * (to avoid
>> + * extraneous page_address() calculations) hence can't use
>> + * use asm-generic/pgalloc.h which assumes it being struct page *
>> + */
> Another reason to leave ARC without asm-generic/pgalloc.h was
> __get_order_pte() that other arches don't have.
> So this and pgtable_t aliased to pte_t * seemed to me too much to bother
> then, but probably it's worth reconsidering with addition of 3rd and 4th
> levels.

I agree that savings of not havign page_address() might not be huge. 
However asm-generic/pgalloc.h only has pte allocation routines and all 
other allocation levels come from arch file

Also for ARCv2, given the arbitrary address split and ensuing paging 
levels (as well as support for different page sizes) we will need to 
make sure that one page is enough to hold any level's paging using say 
BUILD_BUG_ON. In fact that should also be done for 3rd and 4th levels 
for sanity.

-Vineet