From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 9 17:09:16 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E2B1106566B for ; Wed, 9 Nov 2011 17:09:16 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 042328FC08 for ; Wed, 9 Nov 2011 17:09:15 +0000 (UTC) Received: by gyd5 with SMTP id 5so2749022gyd.13 for ; Wed, 09 Nov 2011 09:09:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=KSLlPusoNLl8q2sjnDPJtf0JOkzyo2I5cjrThhXEwQ0=; b=fK1bYE+LAAqhwiqiUNzNtZPbitlbS5X8YSU5EQa2zpE8lVPv5ISlObAAcLBwx0WeKk f2RnqCzGIUctMJLDhRbh/MlB5/Sre5iHcXL4H43gLfdzOnKQoUUVKiPdq1GPeG6NatfH WwB1FEfV8+Q7hs/1M+uvmWdtzLfHO6cZBbz+s= MIME-Version: 1.0 Received: by 10.68.29.197 with SMTP id m5mr6831987pbh.9.1320858554924; Wed, 09 Nov 2011 09:09:14 -0800 (PST) Received: by 10.142.126.2 with HTTP; Wed, 9 Nov 2011 09:09:14 -0800 (PST) Date: Wed, 9 Nov 2011 18:09:14 +0100 Message-ID: From: Svatopluk Kraus To: hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: i386 - pmap_enter() & superpage promotion on kernel addresses X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 17:09:16 -0000 Hi, I'm tuning pmap code for arm11 mpcore port, which is inspired by i386 one. My question is about superpage promotions on kernel addresses in i386 pmap code. pmap_promote_pde() is called from pmap_enter() only and if following conditions are fulfilled: 1. promotions are enabled, 2. all pages in a superpage are allocated (physical space condition), and for user addresses, 3. all pages in a superpage are mapped (virtual space condition). For kernel addresses, the third condition is not checked. I understand that it is not easy to evaluate the third condition for kernel addresses. However, pmap_promote_pde() often can be called unnecessarily now and it's rather expensive call. Or is there any other reason for that? Moreover, there are many temporary mappings (pmap_qenter(),...) in kernel and if pmap_promote_pde() is called without 3th condition, the promotion can be successfull. As temporary mappings do nothing with promotions and demotions, it is a fault. Or a superpage with temporary kernel mapping never can be promoted because of locking or something else? The third condition is evaluated on page table bases (wire_count is used) for user addresses. Page tables for kernel addresses have wire count set to 0 or 1. Page tables preallocated during boot are post-initialized in pmap_init() but wire_count is left untouched (wire_count is 0). Page tables allocated in pmap_growkernel() are allocated wired (wire_count is 1). [branch] If a kernel superpage is demoted in pmap_demote_pde() and corresponding page table wire_count is 1, the page table is re-initialized uselessly as a newly allocated one. My idea is that kernel address mappings made in pmap_enter() can be marked 'stable' (as opposite to 'temporary') and counted by wire_count in same way as for user addresses and then third condition could be applied and will be fulfilled only for this 'stable' mappings (which know about promotions and demotions). Is anything wrong with this idea? Svata