From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45652) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZGy5S-0008S2-PX for qemu-devel@nongnu.org; Sun, 19 Jul 2015 19:33:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZGy5S-0001AN-2a for qemu-devel@nongnu.org; Sun, 19 Jul 2015 19:33:38 -0400 Message-ID: <1437348796.28088.122.camel@kernel.crashing.org> From: Benjamin Herrenschmidt Date: Mon, 20 Jul 2015 09:33:16 +1000 In-Reply-To: <20150719230128.GL11361@aurel32.net> References: <1437258018-13982-1-git-send-email-benh@kernel.crashing.org> <1437258018-13982-3-git-send-email-benh@kernel.crashing.org> <55AB9068.8050202@redhat.com> <20150719230128.GL11361@aurel32.net> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH 3/4] ppc: Use split I/D mmu modes to avoid flushes on interrupts List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Aurelien Jarno Cc: Paolo Bonzini , qemu-ppc@nongnu.org, qemu-devel@nongnu.org On Mon, 2015-07-20 at 01:01 +0200, Aurelien Jarno wrote: > One way to improve this would be to reduce the size of a TLB entry. > Currently we store the page address separately for read, write and > code. The information is therefore quite redundant. > > We might want to have only one page address entry and encode if it is > allowed for read, write or code in the low bits just like we do for > invalid, mmio or dirty. This means the TLB entry can be checked with > > env->tlb_table[mmu_idx][page_index].ADDR == > (addr & (TARGET_PAGE_MASK | (DATA_SIZE - 1))) | READ/WRITE/CODE) > > with READ/WRITE/CODE each being a different bit (they can probably even > replace invalid). In practice it means one more instruction in the fast > path (one or with a 8-bit immediate), but it allows to divide the size > of a TLB entry by two on a 64-bit machine. It might be worth a try. It might but that means "fixing" all tcg backends which I'm not necessarily looking forward to :-) The cost of that one or might be minimum on some processor but I wouldn't bet on it as we have basically all dependent instructions. Ben.