Re: [patch 1/14] mm: opt rmqueue

[Nick Piggin <nickpiggin@yahoo.com.au>]

Andi Kleen wrote:
> On Monday 07 November 2005 02:06, Nick Piggin wrote:
> 
> 
>>Yes, all this turning on and off of interrupts does have a
>>significant cost here.
> 
> 
> How did you find out? 
> 

Measuring the actual performance improvement on kbuild.
Not to mention that profiles for things like mod_page_state
go dramatically down, but you can't use that alone to be sure
of an improvement.

> 
>>With the full patchset applied, most of the hot path statistics
>>get put under areas that already require interrupts to be off,
>>however there are still a few I didn't get around to doing.
>>zone_statistics on CONFIG_NUMA, for example.
> 
> 
> These should just be local_t 
> 

Yep.

> 
>>I wonder if local_t is still good on architectures like ppc64
>>where it still requires an ll/sc sequence?
> 
> 
> The current default fallback local_t doesn't require that. It uses
> different fields indexed by !!in_interrupt()
> 

Right I didn't see that. ppc(32), then.

I think maybe for struct page_state there is not so much point
in using local_t because the hot page allocator paths can easily
be covered under the interrupt critical sections.

The other fields aren't very hot, and using local_t would bloat
this up by many cachelines on 64-bit architectures like ppc64,
and would make them probably noticably more expensive on 32s
like ppc.

Actually, the NUMA fields in the pcp lists can probably also
just be put under the interrupt-off section that the page
allocator uses. At least it should be much easier to do when
Seth's __alloc_pages cleanup goes in. I'll keep it in mind.

-- 
SUSE Labs, Novell Inc.

Send instant messages to your online friends http://au.messenger.yahoo.com