On Wed, 2002-07-24 at 19:25, Andrew Morton wrote:
> I did some testing yesterday with fork/exec/exit-intensive
> workloads and the contention rate on pte_chain_lock was 0.3%,
> so the efficiency problems which Linus described are unlikely
> to bite us in this particular application. But if the usage
> of spin_lock_bit() were to widen, some platforms may be impacted.
At this point (with Linus asking me to keep the "pte_chain_lock()"
interface) I do not really care so long as we not compile the actual
locking on UP.
Will you take this patch, then?
Robert Love
diff -urN linux-2.5.28/include/linux/page-flags.h linux/include/linux/page-flags.h
--- linux-2.5.28/include/linux/page-flags.h Wed Jul 24 14:03:21 2002
+++ linux/include/linux/page-flags.h Thu Jul 25 09:27:01 2002
@@ -228,6 +228,8 @@
#define ClearPageDirect(page) clear_bit(PG_direct, &(page)->flags)
#define TestClearPageDirect(page) test_and_clear_bit(PG_direct, &(page)->flags)
+#ifdef CONFIG_SMP
+
/*
* inlines for acquisition and release of PG_chainlock
*/
@@ -253,6 +255,20 @@
preempt_enable();
}
+#else
+
+static inline void pte_chain_lock(struct page *page)
+{
+ preempt_disable();
+}
+
+static inline void pte_chain_unlock(struct page *page)
+{
+ preempt_enable();
+}
+
+#endif
+
/*
* The PageSwapCache predicate doesn't use a PG_flag at this time,
* but it may again do so one day.
-
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/
This archive was generated by hypermail 2b29 : Tue Jul 30 2002 - 14:00:21 EST