Messages in this thread | | | Date | Sat, 8 Aug 2009 20:34:03 +0100 (BST) | From | Hugh Dickins <> | Subject | CONFIG_PREEMPT_RCU in next/mmotm |
| |
Hi Paul,
Is CONFIG_PREEMPT_RCU=y expected to be working in -next (or mmotm)?
I ask because it appears to break down on PowerPC G5 when I try two "make -j20" kernel builds in parallel. The "filp" slab which usually contains a couple of thousand objects or so, jumps up to a couple of hundred thousand before the builds complete, and continues rising from then on - I think that's a sign of RCU in disgrace? And rebooting hangs thereafter.
And I notice that include/linux/rcupreempt.h currently says: static inline void synchronize_rcu_expedited(void) { synchronize_rcu(); /* Placeholder for new rcupreempt implementation. */ } which gives an impression of work in progress?
CONFIG_PREEMPT_TREE=y seems okay on PowerPC; and when I briefly tried CONFIG_PREEMPT_RCU=y on x86_64, it didn't show above symptoms there.
I did try bisecting yesterday's linux-next git, but that led me to
commit 8ca17c6082feee5841a7b0e91d00e18c3f85f063 Merge: dafcc6e... 7256cf0... Author: Ingo Molnar <mingo@elte.hu> Date: Mon Aug 3 15:50:37 2009 +0200
Merge branch 'core/rcu' into auto-sched-next
rather than to any particular patch of yours which that merges: which seemed odd, but I'm not accustomed to bisecting next.
Another odd thing is that mmotm .DATE=2009-07-30-05-01, the last I tried before Thursday's, showed no such symptoms: yet appears to contain all the larger RCU changes, just lacking some more recent on/offline race fixes. I didn't notice any likely difference between those mmotm trees down in arch/powerpc either.
My guess is that there's some other issue which is triggering the RCU disgrace, but that is just a guess.
Config attached. Any suggestions?
Thanks, Hugh
| |