From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-la0-f46.google.com (mail-la0-f46.google.com [209.85.215.46]) by kanga.kvack.org (Postfix) with ESMTP id 4E8706B0031 for ; Tue, 15 Jul 2014 19:36:49 -0400 (EDT) Received: by mail-la0-f46.google.com with SMTP id b8so85423lan.5 for ; Tue, 15 Jul 2014 16:36:48 -0700 (PDT) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) by mx.google.com with ESMTPS id an5si16076330lac.71.2014.07.15.16.36.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Jul 2014 16:36:47 -0700 (PDT) Received: by mail-lb0-f178.google.com with SMTP id 10so84584lbg.9 for ; Tue, 15 Jul 2014 16:36:46 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <1405465801.28702.34.camel@misato.fc.hp.com> References: <1405452884-25688-1-git-send-email-toshi.kani@hp.com> <1405452884-25688-4-git-send-email-toshi.kani@hp.com> <1405465801.28702.34.camel@misato.fc.hp.com> From: Andy Lutomirski Date: Tue, 15 Jul 2014 16:36:26 -0700 Message-ID: Subject: Re: [RFC PATCH 3/11] x86, mm, pat: Change reserve_memtype() to handle WT type Content-Type: text/plain; charset=UTF-8 Sender: owner-linux-mm@kvack.org List-ID: To: Toshi Kani Cc: "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , Andrew Morton , Arnd Bergmann , Konrad Rzeszutek Wilk , plagnioj@jcrosoft.com, tomi.valkeinen@ti.com, "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Stefan Bader , Dave Airlie , Borislav Petkov On Tue, Jul 15, 2014 at 4:10 PM, Toshi Kani wrote: > On Tue, 2014-07-15 at 12:56 -0700, Andy Lutomirski wrote: >> On Tue, Jul 15, 2014 at 12:34 PM, Toshi Kani wrote: >> > This patch changes reserve_memtype() to handle the new WT type. >> > When (!pat_enabled && new_type), it continues to set either WB >> > or UC- to *new_type. When pat_enabled, it can reserve a given >> > non-RAM range for WT. At this point, it may not reserve a RAM >> > range for WT since reserve_ram_pages_type() uses the page flags >> > limited to three memory types, WB, WC and UC. >> >> FWIW, last time I looked at this, it seemed like all the fancy >> reserve_ram_pages stuff was unnecessary: shouldn't the RAM type be >> easy to track in the direct map page tables? > > Are you referring the direct map page tables as the kernel page > directory tables (pgd/pud/..)? > > I think it needs to be able to keep track of the memory type per a > physical memory range, not per a translation, in order to prevent > aliasing of the memory type. Actual RAM (the lowmem kind, which is all of it on x86_64) is mapped linearly somewhere in kernel address space. The pagetables for that mapping could be used as the canonical source of the memory type for the ram range in question. This only works for lowmem, so maybe it's not a good idea to rely on it. --Andy -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org