Messages in this thread Patch in this message | | | Date | Sat, 14 Aug 2004 08:39:48 +0200 | From | Ingo Molnar <> | Subject | Re: [patch] voluntary-preempt-2.6.8-rc4-O7 |
| |
* Lee Revell <rlrevell@joe-job.com> wrote:
> In some of the traces, like this one: > > http://krustophenia.net/testresults.php?dataset=2.6.8-rc4-bk3-O7#/var/www/2.6.8-rc4-bk3-O7/mount_reiserfs_latency_trace.txt > > there are calls to voluntary_resched. How is this possible? Does it > mean that we called voluntary_resched while holding a spinlock, where > we needed to call voluntary_preempt_lock(&foo_lock), and thus failed > to reschedule?
voluntary_resched() was probably called as part of the might_sleep_if() done in mm/slab.c. If you have CONFIG_DEBUG_SPINLOCK_SLEEP enabled then the kernel should have complained about 'Debug: sleeping function ...'.
but what i think happened here is that reiserfs still uses lock_kernel()/unlock_kernel() quite alot (eg. ext3 or xfs doesnt), which from a preemptability POV is just as much of a critical section as a spinlock, but processes can sleep (the scheduler auto-releases and auto-reacquires the big kernel lock).
Ingo
--- linux/kernel/sched.c.orig +++ linux/kernel/sched.c @@ -3210,11 +3210,11 @@ __setup("voluntary-preempt=", voluntary_ int __sched voluntary_resched(void) { - if (kernel_preemption || !voluntary_preemption) - return 0; #ifdef CONFIG_DEBUG_SPINLOCK_SLEEP __might_sleep(__FILE__, __LINE__); #endif + if (kernel_preemption || !voluntary_preemption) + return 0; /* * The system_state check is somewhat ugly but we might be * called during early boot when we are not yet ready to reschedule. - 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/
| |