On Wed, 08 Aug 2007 16:14:36 -0700 (PDT) David Miller <[EMAIL PROTECTED]> wrote:
> From: "Luck, Tony" <[EMAIL PROTECTED]> > Date: Wed, 8 Aug 2007 16:04:44 -0700 > > > This didn't raise any comment on LKML ... probably the > > "ia64" in the Subject: deterred you all from reading it :-) > > > > I don't think I understand either the migration code or the > > virtual indexed cache issues well enough to figure this out. > > > > Part 2of2 goes on to mess further with this code to cope with > > the idiosyncracies on ia64 (keeping icache and dcache coherent). > > set_pte_at() on sparc64 does all of the D-cache alias handling > that would be necessary for page-cache pages. > > Perhaps someone should see if IA64 can do similar instead of > sprinkling the kernel with flush_whatever() calls at seemingly > arbitrary places. > > set_pte_at() is when mappings change, and you can see exactly how they > are changing and for what address space and virutal address, therefore > there is no reason that caching issues cannot be handled in it. > > pte_clear() is implemented using set_pte_at() on sparc64, which allows > it to cover all PTE changes made by the kernel in any context. > Hmm...sprinking and messy. Why I added sync_icache_dcache() as new macro is that the places where sync_icache_dcache() is necessary are different from flush_(i)cache_page(). But I admit that "where sync_icache_dcache() should be inserted" is complexed. In older version, I added flush_icache_page()/flush_cache_page() for ia64. This can fix the problem without new macro, but nacked by Zoltan because we have to sync icache-dcache too much. In May, [EMAIL PROTECTED] just moved lazy_mmu_prot_update() to proper place, but Nacked because it just hides wrong macro definition, lazy_mmu_prot_update(). (This was 2 lines patch.) Hmm...should I post flush_(i)cache_page() for ia64 again ? It will be the neatest, maybe. Thanks, -Kame - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
