Messages in this thread | | | Date | Fri, 13 Apr 2007 17:26:43 -0600 | From | Robert Hancock <> | Subject | Re: Why kmem_cache_free occupy CPU for more than 10 seconds? |
| |
Zhao Forrest wrote: > These 2 kernel options are turned on by default in my kernel. Here's > snip from .config > # CONFIG_PREEMPT_NONE is not set > CONFIG_PREEMPT_VOLUNTARY=y > # CONFIG_PREEMPT is not set > CONFIG_PREEMPT_BKL=y > CONFIG_NUMA=y > CONFIG_K8_NUMA=y > >> >> Does this fix it? >> >> --- fs/buffer.c~ 2007-02-01 12:00:34.000000000 +0100 >> +++ fs/buffer.c 2007-04-11 12:35:48.000000000 +0200 >> @@ -3029,6 +3029,8 @@ out: >> struct buffer_head *next = bh->b_this_page; >> free_buffer_head(bh); >> bh = next; >> + >> + cond_resched(); >> } while (bh != buffers_to_free); >> } >> return ret; >> > So far I have run the test with patched kernel for 6 rounds, and > didn't see the soft lockup. I think this patch should fix the problem. > But what still confused me is that why do we need to invoke > cond_resched() voluntarily since CONFIG_PREEMPT_VOLUNTARY and > CONFIG_PREEMPT_BKL are both turned on? From my understanding these 2 > options should make schedule happen even if CPU is under heavy > load......
No, only CONFIG_PREEMPT will do that.
-- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from hancockr@nospamshaw.ca Home Page: http://www.roberthancock.com/
- 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/
| |