On Thursday 24 July 2008 00:12, Nick Piggin wrote:
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
somewhere?
--
