By the way, for the benefit of anybody finding this thread in the future:

I found a similar problem with taking a page fault for an mmap'd file
implemented in fuse. The kernel blocks with this stack:

     [<0000000000000000>] wait_answer_interruptible+0x6a/0xa0
     [<0000000000000000>] __fuse_request_send+0x1fb/0x280
     [<0000000000000000>] fuse_request_send+0x12/0x20
     [<0000000000000000>] fuse_readpage+0x152/0x1e0
     [<0000000000000000>] filemap_fault+0x116/0x410
     [<0000000000000000>] __do_fault+0x6f/0x530
     [<0000000000000000>] handle_mm_fault+0x482/0xf00
     [<0000000000000000>] __do_page_fault+0x184/0x560
     [<0000000000000000>] do_page_fault+0x1a/0x70
     [<0000000000000000>] page_fault+0x28/0x30
     [<0000000000000000>] 0xffffffffffffffff

and my test deadlocks with the faulting thread camping on the Go scheduler slot
and the fuse thread waiting for the scheduler slot. (The workaround in the
particular case of this test is to just raise GOMAXPROCS, of course.)

It seems like this probably comes up for files mmap'd from a "real" file
systems, too: while waiting on disk access for a page fault, the scheduler will
fail to utilize the CPU. But I don't see anything obvious that can be done
about it.


You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

Discussion Posts


Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 10 of 10 | next ›
Discussion Overview
groupgolang-nuts @
postedMar 20, '15 at 4:01a
activeMar 23, '15 at 12:13a



site design / logo © 2021 Grokbase