Re: [PATCH] anobjrmap 9 priority mjb tree

[Martin J. Bligh]

>> I applied Andrew's high sophisticated proprietary semtrace technology.
> 
> Thanks a lot, Martin, this seems pretty important.
> 
> So, i_shared_sem, as you supposed.
> 
> Do you still have the two profiles input to diffprofile?
> I wonder if they'd have clues to help us understand it better.

Yup. Attatched.

> Any chance of you doing the same comparison between 2.6.5-aa5 
> 2.6.5-aa5 minus prio-tree?  (Well, needn't be -aa5, whatever comes to
> hand.  Looks like "patch -p1 -R < prio-tree" mostly works, just some
> rejects in mm/mmap.c itself, let me know if I can help out on that.)
> 
> If -aa is okay, I hope so, then it's surely some stupidity from me.

Good idea. Not sure how easy it'll be to back prio_tree out, but I can 
surely do aa5, which would give us a good clue still. Might not be until 
this time tommorow though.

> We're not at all surprised that vma linking and unlinking should take
> rather longer; but the rise in __down, __wake_up, finish_task_switch
> is horrifying.  Or is that how it usually looks, when a semaphore is
> well contended - thundering herd?

I think there's just a locking cliff you fall off after a certain level
of contention ... i_shared_sem has always been bad for SDET, to be fair.
But I hate making it worse ;-) I did more investigation of it a year or
so ago ... something does horrible things to it (which is why akpm turned
it into a sem in the first place) ... maybe holding it over proess teardown
for eons or something. Bah, I want lockmeter for sems ;-) 

Maybe I can dig out my old analysis ... I'll take a look. I suppose I could
always turn it back into a spinlock to look at it ;-) On the other hand, if
we can fix that problem, I think my "list of lists" was simpler than prio
tree (and is probably much more susceptible to RCU).

M.

Attachment: mjb1
Description: Binary data

Attachment: mjb1-prio
Description: Binary data