Linux Scalability Effort

Ray Bryant <raybry@...> wrote:
>
> For large address spaces, and lots of threads (large here means 50-100GB, and 32 or more threads pinned to that many 
> cpus), we're seeing severe contention on the mm->page_table_lock in do_anonymous_page() and handle_mm_fault().  The 
> effect of this is that after a (Fortran) program allocates storage via mmap() it can take minutes for the application to 
> really start while all of the data pages are touched and anonymous paged into the address space.  This can limit SMP 
> speedups significantly (fortunately benchmarks often don't start timing until after this start up interval).

It seems like a fairly special case: perhaps not common enough to be making
kernel changes.  Is it not acceptable to work around it in userspace?  Make
one thread fault all the pages in before starting all the others?

We could extend MAP_POPULATE to fault all the pages in, but that's much the
same thing.

On Mon, Sep 22, 2003 at 10:27:38PM -0500, Ray Bryant wrote:
> For large address spaces, and lots of threads (large here means 50-100GB, 
> and 32 or more threads pinned to that many cpus), we're seeing severe 
> contention on the mm->page_table_lock in do_anonymous_page() and 
> handle_mm_fault().  The effect of this is that after a (Fortran) program 

I have seen this problem on smaller NUMA systems with smaller loads
too:

Just have one process that exceeds its working set all the time. On another
CPU the swapper will run continuously and age its working set. The process
does page faults all the time because of its unmapped aged pages.

In one particularly base case the two CPUs doing this were near completely
busy just fighting for page_table_lock and sending TLB flush IPIs 
to each other. Workload made nearly no progress.

I saw this case on 2.4, but I suspect it's in 2.6 too, just maybe
harder to trigger.

- Possible solutions: do batched swapping and take the lock
only for multiple pages (not sure if that would help in your case,
making the normal user page fault use batched locking is probably a lot of
work) 

- Use a more fair queued lock for the page_table_lock
This would make the common case slightly slower though.

-Andi

On Fri, Sep 26, 2003 at 10:02:15PM -0700, Andrew Morton wrote:
> Andi Kleen <ak@...> wrote:
> >
> > I saw this case on 2.4, but I suspect it's in 2.6 too, just maybe
> >  harder to trigger.
> > 
> >  - Possible solutions: do batched swapping and take the lock
> >  only for multiple pages (not sure if that would help in your case,
> >  making the normal user page fault use batched locking is probably a lot of
> >  work) 
> 
> That's what 2.4 does do, effectively.  swap_out_mm() takes the mm's
> page_table_lock and hangs onto it for dear life.

Hmm, I had heavy contention. I did some profiling and roughly 30% was
spent spinning on the lock and 70% processing or sending IPIs.

Batching the IPI TLB flushes would probably help (I proposed that on KS),
but something needs to be done about the lock too.

-Andi

Andi Kleen <ak@...> wrote:
>
> I saw this case on 2.4, but I suspect it's in 2.6 too, just maybe
>  harder to trigger.
> 
>  - Possible solutions: do batched swapping and take the lock
>  only for multiple pages (not sure if that would help in your case,
>  making the normal user page fault use batched locking is probably a lot of
>  work) 

That's what 2.4 does do, effectively.  swap_out_mm() takes the mm's
page_table_lock and hangs onto it for dear life.

Andi Kleen <ak@...> wrote:
>
> > That's what 2.4 does do, effectively.  swap_out_mm() takes the mm's
>  > page_table_lock and hangs onto it for dear life.
> 
>  Hmm, I had heavy contention. I did some profiling and roughly 30% was
>  spent spinning on the lock and 70% processing or sending IPIs.

Well rmap changes that stuff completely, so the first step is to verify
that 2.6 actually has a problem.

<<Watch this space>>

At the moment, I don't have access to a 2.6 for Altix that is stable enough to run this test, but when we get one that 
does, I will retest and see.

Andrew Morton wrote:
> Andi Kleen <ak@...> wrote:
> 
>>>That's what 2.4 does do, effectively.  swap_out_mm() takes the mm's
>>
>> > page_table_lock and hangs onto it for dear life.
>>
>> Hmm, I had heavy contention. I did some profiling and roughly 30% was
>> spent spinning on the lock and 70% processing or sending IPIs.
> 
> 
> Well rmap changes that stuff completely, so the first step is to verify
> that 2.6 actually has a problem.
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Lse-tech mailing list
> Lse-tech@...
> https://lists.sourceforge.net/lists/listinfo/lse-tech
> 

-- 
Best Regards,
Ray
-----------------------------------------------
                   Ray Bryant
512-453-9679 (work)         512-507-7807 (cell)
raybry@...             raybry@...
The box said: "Requires Windows 98 or better",
            so I installed Linux.
-----------------------------------------------