Messages in this thread | | | Subject | Re: Why kmem_cache_free occupy CPU for more than 10 seconds? | From | Peter Zijlstra <> | Date | Wed, 11 Apr 2007 12:16:55 +0200 |
| |
On Wed, 2007-04-11 at 18:10 +0800, Zhao Forrest wrote: > On 4/11/07, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote: > > On Wed, 2007-04-11 at 02:53 -0700, Paul Jackson wrote: > > > I'm confused - which end of ths stack is up? > > > > > > cpuset_exit doesn't call do_exit, rather it's the other > > > way around. But put_files_struct doesn't call do_exit, > > > rather do_exit calls __exit_files calls put_files_struct. > > > > I'm guessing its x86_64 which generates crap traces. > > > Yes, it's x86_64. Is there a reliable way to generate stack traces under x86_64? > Can enabling "[ ] Compile the kernel with frame pointers" help?
Sometimes, the best is to redo the undo of the dwarf based stack unwinder.
But as you said, that _huge_ number of buffers might be the issue, I'm looking through the codepaths from __blkdev_put on downwards, I suspect we hold a single lock somewhere,...
So hold on with patching the unwinder back in (unless of course you fancy doing so :-)
- 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/
| |