[2.4] [PATCH] hash_page rework, take 2
Julie DeWandel
jdewand at redhat.com
Wed Feb 4 06:12:42 EST 2004
Clarification/update on 2 points.
>
>- spin_unlock(&hash_table_lock[lock_slot].lock);
>+out_unlock:
>+ smp_wmb();
>
>JSD: I believe an smp_mb__before_clear_bit() would be a better choice, or
>JSD: at least an lwsync because this is an unlock.
>
>+
>+ pte_val(*ptep) &= ~_PAGE_BUSY;
>
>- return 0;
>+ return ret;
> }
>
> /*
>
JSD: I should have added that the clearing of the _PAGE_BUSY bit should be
JSD: done using an atomic op (clear_bit() routine)
>diff -pru -X /root/.diffexclude linux-2.4.21-6.EL-just_tools/arch/ppc64/mm/init.c hashpage/arch/ppc64/mm/init.c
>--- linux-2.4.21-6.EL-just_tools/arch/ppc64/mm/init.c 2004-01-06 20:35:23.000000000 -0600
>+++ hashpage/arch/ppc64/mm/init.c 2004-01-18 18:11:14.000000000 -0600
>
>+static inline void pte_free_sync(void)
>+{
>+ unsigned long flags;
>+ int i;
>+
>+ /* All we need to know is that we can get the write lock if
>+ * we wanted to, i.e. that no hash_page()s are holding it for reading.
>+ * If none are reading, that means there's no currently executing
>+ * hash_page() that might be working on one of the PTE's that will
>+ * be deleted. Likewise, if there is a reader, we need to get the
>+ * write lock to know when it releases the lock.
>+ */
>+
>+ for (i = 0; i < smp_num_cpus; i++)
>+ if (is_read_locked(&pte_hash_lock[i])) {
>+ if(i == smp_processor_id())
>+ local_irq_save(flags);
>+
>+ write_lock(&pte_hash_lock[i]);
>+ write_unlock(&pte_hash_lock[i]);
>+
>+ if(i == smp_processor_id())
>+ local_irq_restore(flags);
>+ }
>+}
>
>JSD: Two questions here. (1) Shouldn't interrupts be disabled for the
>JSD: write_lock/unlock here regardless of what processor we are running
>JSD: on? (2) I don't see how this code is preventing another processor
>JSD: from grabbing the read_lock immediately after this processor has
>JSD: checked to make sure it isn't held.
>
JSD: Better question for (1) is why are interrupts being disabled here?
JSD: Can this routine be called from interrupt context?
--
Julie DeWandel <jdewand at redhat.com>
Red Hat, Inc.
Tel (978) 692-3113 x23251
** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/
More information about the Linuxppc64-dev
mailing list