[haiku-bugs] Re: [Haiku] #5773: vm_page_fault after adding graph

  • From: "bonefish" <trac@xxxxxxxxxxxx>
  • Date: Thu, 22 Apr 2010 15:15:02 -0000

#5773: vm_page_fault after adding graph
------------------------------------------+---------------------------------
 Reporter:  andreasf                      |       Owner:  axeld         
     Type:  bug                           |      Status:  new           
 Priority:  normal                        |   Milestone:  R1            
Component:  Applications/ActivityMonitor  |     Version:  R1/Development
 Keywords:                                |   Blockedby:                
 Platform:  x86                           |    Blocking:                
------------------------------------------+---------------------------------

Comment(by bonefish):

 Replying to [comment:6 andreasf]:
 > Normally with three graphs ActivityMonitor memory usage is around 1.4 MB
 according to ProcessController. With a dozen graphs and the hang it
 skyrocketed over 800 MB and kept climbing.

 Indeed. The stack trace seems to indicate that it just tried to allocate
 another area and failed (probably due to lack of resources -- though
 {{{avail}}} still shows almost 900 MB available).

 > Overall used memory according to AboutSystem went from maybe 120 MB to
 only around 390 MB and stagnated there. RAM is 1 GB, swap 2 GB.

 I'm not quite sure what stats AboutSystem's info is based on, but
 {{{page_stats}}} and {{{avail}}} (well, I forgot {{{swap}}}) give a
 detailed picture. There are only 4446 free pages and 781 cached ones.
 There are 40969 wired ones, which is quite a lot, unless you have kernel
 tracing enabled with a sizable buffer. And we have 201358 inactive pages
 (i.e. actually (but not very recently) used ones), which were probably
 mostly allocated by ActivityMonitor. An {{{areas <team id>}}} for
 ActivityMonitor would be interesting.

 > The page_writer(?) thread in the kernel_team got pretty active at first
 but calmed down again.

 This is expected when a team is allocating obscene amounts of memory, as
 it's the one swapping out pages. The page daemon should probably be even
 busier in the beginning. At least the low memory situation explains why
 the whole system slows down. That doesn't explain the crash, but without a
 stack trace there's little that can be done about it.

 The "PageWriteWrapper: Failed to write page" output is probably related to
 [http://dev.haiku-
 os.org/browser/haiku/trunk/src/system/kernel/port.cpp#L667] and basically
 harmless.

-- 
Ticket URL: <http://dev.haiku-os.org/ticket/5773#comment:7>
Haiku <http://dev.haiku-os.org>
Haiku - the operating system.

Other related posts: