Hi. On Wed, 2005-07-06 at 13:34, Zwane Mwaikambo wrote: > On Wed, 6 Jul 2005, Nigel Cunningham wrote: > > > diff -ruNp > > 353-disable-highmem-tlb-flush-for-copyback.patch-old/mm/highmem.c > > 353-disable-highmem-tlb-flush-for-copyback.patch-new/mm/highmem.c > > --- 353-disable-highmem-tlb-flush-for-copyback.patch-old/mm/highmem.c > > 2005-06-20 11:47:32.000000000 +1000 > > +++ 353-disable-highmem-tlb-flush-for-copyback.patch-new/mm/highmem.c > > 2005-07-04 23:14:20.000000000 +1000 > > @@ -26,6 +26,7 @@ > > #include <linux/init.h> > > #include <linux/hash.h> > > #include <linux/highmem.h> > > +#include <linux/suspend.h> > > #include <asm/tlbflush.h> > > > > static mempool_t *page_pool, *isa_page_pool; > > @@ -95,7 +96,10 @@ static void flush_all_zero_pkmaps(void) > > > > set_page_address(page, NULL); > > } > > - flush_tlb_kernel_range(PKMAP_ADDR(0), PKMAP_ADDR(LAST_PKMAP)); > > + if (test_suspend_state(SUSPEND_FREEZE_SMP)) > > + __flush_tlb(); > > + else > > + flush_tlb_kernel_range(PKMAP_ADDR(0), PKMAP_ADDR(LAST_PKMAP)); > > } > > > > static inline unsigned long map_new_virtual(struct page *page) > > What state are the other processors in when you hit this path?
Looping in arch specific code, waiting for an atomic_t to tell them it's time to restore state and carry on. They're there the whole time CPU0 is restoring the image and highmem. Regards, Nigel -- Evolution. Enumerate the requirements. Consider the interdependencies. Calculate the probabilities. Be amazed that people believe it happened. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
