Re: [PATCH] anobjrmap 9 priority mjb tree

["Martin J. Bligh" <mbligh@aracnet.com>]

>> FYI, even without prio-tree, I get a 12% boost from converting i_shared_sem
>> into a spinlock. I'll try doing the same on top of prio-tree next.
> 
> Good news, though not a surprise.
> 
> Any ideas how we might handle latency from vmtruncate (and
> try_to_unmap) if using prio_tree with i_shared_lock spinlock?

I've been thinking about that. My rough plan is to go wild, naked and lockless.
If we arrange things in the correct order, new entries onto the list would
pick up the truncated image of the file (so they'd be OK). Entries removed
from the list don't matter anyway. We just need to make sure that everything
that was on the list when we start does get truncated.

Basically there are two sets of operations ... ones that map and unmap
the file object (address_space) and ones that alter it - we should be
able to proceed with inserts and deletes whilst truncating, though we
probably need to protect against the alterations. The two op types could
go under separate locking.

But I need to think on it some more - would not suprise me to come to the
conclusion that I'm full of shit ;-) The opinions of others would be
very welcome ...

M.