Messages in this thread | | | Date | Fri, 05 Jul 2002 02:41:57 -0700 | From | Andrew Morton <> | Subject | Re: [patch 18/27] always update page->flags atomically |
| |
Russell King wrote: > > On Thu, Jul 04, 2002 at 04:54:50PM -0700, Andrew Morton wrote: > > It had no right to go clearing PG_arch_1. I'm now clearing PG_arch_1 > > inside rmqueue() which is still a bit presumptious. > > Davem should know the right behaviour for this bit. It's not a generic > "architecture" bit, but it has some defined behaviour behind it. See > cachetlb.txt: > > void flush_dcache_page(struct page *page) > ... > There is a bit set aside in page->flags (PG_arch_1) as > "architecture private". The kernel guarantees that, > for pagecache pages, it will clear this bit when such > a page first enters the pagecache. > > I think you may have broken this... ;(
For pagecache pages we're OK - they're only added to pagecache once, and PG_arch_1 is cleared at page allocation time.
However swapcache pages are added and removed.
It's rather moot, because swapcache pages are not subject to flush_dcache_page() any more. If you're using swap-over-NBD then I guess networking makes its own arrangements...
So hmmm. Actually, I think the current behaviour is correct. If a page is added to swapcache then removed then added, then removed, the kernel should never stomp on PG_arch_1. That's an arch-private cache to say "you need to perform cache writeback for this page if another mm later shares it", yes? So we need to preserve that info as the page enters and leaves swapcache.
I think.
- - 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/
| |