[lkml]   [2008]   [Jul]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: GRU driver feedback
    On Thursday 24 July 2008 00:12, Nick Piggin wrote:

    > Meanwhile, I hope that gives a bit to go on. I'm sorry it has come
    > relatively late in the game, but I had a week off a while back then had
    > (have) some important work work I'm starting to get a handle on...
    > Thanks,
    > Nick

    Couple of other things I noticed today before I launch into the mmu
    notifier and TLB invalidate code proper.

    - gru_invalidate_range_end -- atomic_dec can filter into wake_up_all, past
    the spin_lock in __wake_up, and past the loading of the list of tasks. So
    you can lose a wakeup I believe (not on x86, but on ia64 with release
    ordering spinlocks it would be possible). atomic_dec_and_test should do
    the trick, and you might also want to consider memory ordering of the
    atomic_inc (haven't really looked, but it seems quite suspicious to allow
    it be reordered).

    - you seem to be using cache flushes and memory barriers in different ways
    but each to push out things to the GRU device. For example start_instruction
    does a wmb() then a store, then a CPU cache flush.

    I'm lost as to how the mmio protocol actually works (not the low level
    protocol, but exactly what cache attributes are used, and how the CPU
    pushes things to the device and vice versa).

    For example, if you are using wmb(), this I think implies you are using
    UC or WC memory to map the device, in which case I don't see why you need
    the gru_flush_cache (which would suggest WB memory). Is this documented

     \ /
      Last update: 2008-07-24 04:45    [W:0.020 / U:5.716 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site