lkml.org 
[lkml]   [2008]   [Sep]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: PTE access rules & abstraction
    From
    Date

    > Yes, that sounds fine in principle, but the practise gets tricky. The
    > trouble with that kind of interface is that it can be fairly heavyweight
    > unless you amortise the cost of the transaction setup/commit with
    > multiple operations.

    I agree. Anyway, I'm sure if we get everybody around the same table, we
    can find something, maybe not that high level, but a better set of
    accessors that fits all needs with a more precise semantic. Anyway, I'll
    see if I can come up with ideas later that we can discuss.

    It's also all inline so it does give us flexibility in having things
    compile down to nothing on archs where they aren't needed.

    > Are you using the lazy_mmu hooks we put in, or something else?

    Yes. We used to do it differently but it was actually racy in a subtle
    way, and I switched it to use your lazy_mmu hooks a while ago.

    > Likely; it's one of those overused generic words. The specific meaning
    > I'm using is "we can roll a bunch of updates into a single hypercall".
    > Operations which do atomic RMW or fetch-set are typically not batchable
    > because the caller wants the result *now* and can't wait for a deferred
    > result.

    Right. For us it's mostly about flushing the hash entries, though there
    is no fundamental difference I believe here, it's about updating a
    cache, whether it's the TLB, our hash table, hypervisor shadows, etc...
    and we -should- be able to find a more sensible common ground.

    Cheers,
    Ben.




    \
     
     \ /
      Last update: 2008-09-25 00:57    [W:0.020 / U:1.856 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site