This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: double fault -> PAGE_KERNEL flagged memory


Mathieu Desnoyers writes:
 > * Tom Zanussi (zanussi@us.ibm.com) wrote:
 > > Mathieu Desnoyers writes:
 > >  > * Tom Zanussi (zanussi@us.ibm.com) wrote:
 > >  > > Mathieu Desnoyers writes:
 > >  > >  > Generally speaking, what would happen if :
 > >  > >  > 
 > >  > >  > - A page fault handler has a trace point that logs an event in the RelayFS
 > >  > >  >   buffer.
 > >  > >  > - This exact write causes a (minor) page fault.
 > >  > >  > 
 > >  > >  > It may not happen often, but I think it would lead to a double fault. Is this
 > >  > >  > case possible ?
 > >  > >  > 
 > >  > > 
 > >  > > Yes, I'm sure it is possible, in fact I'm sure it happens all the time
 > >  > > in LTT and it's never been a problem.  Have you verified that it is a
 > >  > > problem (e.g. tracing only page faults and seeing a double fault).
 > >  > > 
 > >  > > 
 > >  > 
 > >  > I have just done this, and nothing bad happened and I discovered why :
 > >  > 
 > >  > The LTT instrumentation of do_page_fault comes right after the
 > >  > "We fault-in kernel-space virtual memory on-demand." section. So, minor page
 > >  > faults are not instrumented.
 > >  > 
 > >  > Maybe this isn't so interesting to instrument it, but if we would like to, I
 > >  > suggest to add an optionnal support for kmalloc'd memory areas in RelayFS so
 > >  > the client can ask for a channel which consists of a small buffer that is
 > >  > reentrant for the memory subsystem. This should be documented with a big
 > >  > warning about the small size the client should ask for.
 > >  > 
 > > 
 > > That would be one option, but how about instrumenting the vmalloc
 > > fault case to check whether the faulting address lies inside the
 > > buffer and if so, don't log an event in that case.  You wouldn't see
 > > those vmalloc faults touching the relayfs buffers, but I'm not sure
 > > that's interesting anyway...
 > > 
 > 
 > What about :
 > - On any minor page fault
 >   - logging a vmalloc fault (from somewhere else in the kernel)
 >     - test if faulted address lies within the relayfs buffer : no
 >     - generate a vmalloc fault because of buffer access
 >       -> double fault.
 > 
 > I'm afraid it won't fix the problem.
 > 

I just tried a simple experiment instrumenting do_page_fault() to log
in the same spot LTT does, and also at the very end of of the
vmalloc_fault case, and see the vmalloc faults (to the relayfs buffer,
caused by a write from another page fault, since that's all that's
instrumented) being logged without double faults.  So you don't even
have to test whether the fault is in the relayfs buffer, just wait
until the page table has been updated.  What would cause a double
fault would be if the vmalloc_fault tried logging before the page
table was updated, which would cause the same vmalloc fault.

Tom




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]