Messages in this thread | | | Date | Sun, 11 Apr 2004 10:28:05 -0700 | From | "Martin J. Bligh" <> | Subject | Re: [PATCH] anobjrmap 9 priority mjb tree |
| |
>> 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.
[unhandled content-type:application/octet-stream][unhandled content-type:application/octet-stream] | |