Date: Mon, 19 Apr 2004 17:54:57 -0500
From: Terence Ripperda <tripperda@nvidia.com>
To: Andi Kleen <ak@muc.de>
Cc: Terence Ripperda <tripperda@nvidia.com>, linux-kernel@vger.kernel.org,
       eich@suse.de
Subject: Re: PAT support
Message-ID: <20040419225456.GM632@hygelac>
Reply-To: Terence Ripperda <tripperda@nvidia.com>
References: <20040417004217.GC72227@colin2.muc.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040417004217.GC72227@colin2.muc.de>
User-Agent: Mutt/1.4i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2053
Lines: 33

On Fri, Apr 16, 2004 at 05:42:17PM -0700, ak@muc.de wrote:
> change_page_attr can change more than just caching attributes,
> also read/write (e.g. slab debug uses it for that) 

ah, ok. sorry, missed that.

> At least for the later adding another book keeping data structure
> may be too expensive.

makes sense.

> I think I prefer the do/undo model instead of push/pop.
> That can work with cmaps too. PAGE_KERNEL means no cmap,
> PAGE_KERNEL_WC and PAGE_KERNEL_NOCACHE get a cmap.

but then what is the point of cmap? I would expect a mix of WC and UC mappings to be much less dangerous than a mix of WC/UC and WB. perhaps my mindset is wrong, but it seems allowing ioremap to request a cached mapping is important, and that if that mapping was followed by ioremap_nocached or ioremap_wrcomb, that these subsequent calls should fail.

I did finish implementing your suggestion, that change_page_attr should consider PAGE_KERNEL as a call to cmap_release_range and anything else as a call to cmap_request_range. seemed to work ok, but I'm seeing the acpi table code doing a lot of ioremaps (cached) that are ignored, then iounmaps are causing cmap_release_range calls to complain about not finding the regions. of course in a final version, we'd cut out the debug output, but expecting lots of empty calls to cmap_release_range seems messy.

what if there was a restore_page_attr(unsigned long address, unsigned long numpages) that assumed the pgprot was PAGE_KERNEL. change_page_attr knows to call cmap_request_range and restore_page_attr knows to call cmap_release_range. otherwise they do the same thing, restore_ just inherently uses PAGE_KERNEL for the caching type.

> remove_vm_area() needs to just be split into some worker functions 
> (__remove_vm_area et.al.)

ok, easily done.

Thanks,
Terence
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/