[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: tmpfs replacement
From: |
Roland McGrath |
Subject: |
Re: tmpfs replacement |
Date: |
Wed, 13 Aug 2003 17:07:20 -0400 (EDT) |
The only interesting thread is the last one. The others are service
threads waiting for something to do, which is normal. When showing cold
backtraces, always include "x/i $pc" and "info regs" as well. It's
annoying that the arguments are omitted from most of the frames from "bt
full", like the pager_memcpy call. Anyway, we can suspect that getting
that info would show that do_memcpy got a mapping and that memcpy is hung
in the rep;stosl insn with esi/edi being the DATA argument to
_diskfs_rdwr_internal (which should be the OTHER argument to pager_memcpy
as well, not shown in the backtrace) and the page just got from vm_map. If
that's so, it means the hang is in a page fault on that newly-mapped page.
That means all the troubles are actually in the default pager (or kernel).
After verifying that the above is what's happening and vm_map was happy,
you need to start tracing the interactions of the default pager and the
kernel.
If debugging the live default pager turns into a nightmare, it may be
worthwhile to do a little hacking so you can run a hacked mach-defpager
server that is not installed as the kernel's default pager, which you
separately use for tmpfs's default_pager_object_create.