Re: [PATCH] anobjrmap 9 priority mjb tree

From: Martin J. Bligh
Date: Mon Apr 12 2004 - 16:33:29 EST


--On Monday, April 12, 2004 14:12:44 -0700 Andrew Morton <akpm@xxxxxxxx> wrote:

> "Martin J. Bligh" <mbligh@xxxxxxxxxxx> wrote:
>>
>> Turns out he'd turned the
>> locking in find_get_page from "spin_lock(&mapping->page_lock)" into
>> "spin_lock_irq(&mapping->tree_lock)",
>
> That's from the use-radix-tree-walks-for-writeback code.
>
> Use oprofile - it's NMI-based.
>
>> and I'm using readprofile, which
>> doesn't profile with irqs off, so it's not really disappeared, just hidden.
>> Not sure which sub-patch that comes from, and it turned out to be a bit of
>> a dead end, but whilst I'm there, I thought I'd point out this was contended,
>> and show the diffprofile with and without spinline for aa5:
>>
>> 22210 246777.8% find_trylock_page
>> 2538 36.4% atomic_dec_and_lock
>
> profiler brokenness, surely. Almost nothing calls find_trylock_page(),
> unless Andrea has done something peculiar. Use oprofile.

Well, he did do this:

@@ -413,11 +412,11 @@ struct page *find_trylock_page(struct ad
{
struct page *page;

- spin_lock(&mapping->page_lock);
+ spin_lock_irq(&mapping->tree_lock);
page = radix_tree_lookup(&mapping->page_tree, offset);
if (page && TestSetPageLocked(page))
page = NULL;
- spin_unlock(&mapping->page_lock);
+ spin_unlock_irq(&mapping->tree_lock);
return page;
}

Which would stop it appearing in readprofile. But why spinlock inlining
should affect that one way or the other is beyond me. I'll see about
using oprofile, but it's not a trivial conversion (it's all scripted).
There's no other occurences of that in his patchset. But you're right,
only xfs, and free_swap_and_cache seem to use it, and I'm not swapping.

M.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/