Messages in this thread | | | Date | Fri, 26 Sep 2008 12:57:25 -0400 | From | Masami Hiramatsu <> | Subject | Re: [RFC PATCH v4] Unified trace buffer |
| |
Peter Zijlstra wrote: > On Fri, 2008-09-26 at 06:45 -0400, Steven Rostedt wrote: >> On Fri, 26 Sep 2008, Peter Zijlstra wrote: >>> On Thu, 2008-09-25 at 23:20 -0400, Mathieu Desnoyers wrote: >>>> You could also fallback on a 2-level page array when buffer size is > >>>> 64MB. The cost is mainly a supplementary pointer dereference, but one >>>> more should not make sure a big difference overall. >>> I'm still not sure why we don't just link the pages using the page >>> frames, we don't need the random access, do we? >> Yeah we can go back to that (as ftrace does). >> >> 1) It can be very error prone. I will need to encapsulate the logic more. > > Sure. > >> 2) I'm still not sure if crash can handle it. > > It ought to, and if it can't it should be fixed. Having easy access to > the pageframes is vital to debugging VM issues. So I'd not bother about > this issue too much. > >> I was going to reply to Masami with this answer, but it makes things more >> complex. For v1 (non RFC v1) I wanted to start simple. v2 can have this >> enhancement. > > Right - I just object to having anything vmalloc.
I just requested that the expansion of buffer size limitation too. :)
I don't stick with vmalloc. If that (page frame chain?) can achieve better performance, I agree that trace buffer uses it.
Thank you,
-- Masami Hiramatsu
Software Engineer Hitachi Computer Products (America) Inc. Software Solutions Division
e-mail: mhiramat@redhat.com
| |