Re: Why kmem_cache_free occupy CPU for more than 10 seconds?

[Robert Hancock <hancockr@shaw.ca>]

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/