lkml.org 
[lkml]   [2009]   [Jun]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [tip:perfcounters/core] x86: Add NMI types for kmap_atomic
    From
    Date
    On Mon, 2009-06-15 at 20:42 +0200, Ingo Molnar wrote:
    > * Peter Zijlstra <peterz@infradead.org> wrote:
    >
    > > On Mon, 2009-06-15 at 20:25 +0200, Ingo Molnar wrote:
    > > > * Peter Zijlstra <peterz@infradead.org> wrote:
    > >
    > > > but ... look at the APIs i propose above. We dont need _any_
    > > > 'types'.
    > > >
    > > > That type enumeration is basically an open-coded allocator. If we do
    > > > a _real_ allocator (a balanced stack of atomic kmaps) we dont need
    > > > any of those indices, and all the potential for mismatch goes away
    > > > as well - a stack nests trivially with IRQ and NMI and arbitrary
    > > > other contexts.
    > >
    > > You want types because:
    > > - they encode the intent, and can be verified
    > > - they help keep track of the max nesting depth
    > >
    > > In the proposed implementation all type code basically falls away
    > > no ! CONFIG_DEBUG_VM, but is kept around for robustness.
    >
    > But much of the fragility of the types (and their clumsiness - for
    > example in highpte ops we have to know at which level of the
    > pagetables we are, and use the right kind of index) is _precisely_
    > because we have the types ...

    How will you manage the max depth?



    \
     
     \ /
      Last update: 2009-06-15 20:51    [W:0.028 / U:0.172 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site