[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