page fault fastpath patch v2: fix race conditions, stats for 8,32 and 512 cpu SMP
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
Hi Hugh,
Quoted 3 lines · Hugh Dickins
On Tue, 17 Aug 2004, Christoph Lameter wrote:
<snip>
Quoted 5 lines
Just handling that one anonymous case is not worth it, when we know that the next day someone else from SGI will post a similar test which shows the same on file pages ;)
Hugh -- this is called full employment for kernel scalability analysts. :-) :-)
Actually, disks are so slow that I wouldn't expect that scalability problem to show up in the page fault code, but rather in the block I/O or page cache management portions of the code instead.
<snip>
Quoted 7 lines
Quoted 3 lines
Introducing the
page_table_lockeven for a short time makes performance drop to the level before the patch.That's interesting, and disappointing.
I think that the major impact here is actually grabbing the lock when
30 or more processors are trying to obtain it -- the amount of time that the lock is actually held is insignificant in comparison.
Quoted 4 lines
The main lesson I took from your patch (I think wli was hinting at the same) is that we ought now to question
page_table_lockusage, should be possible to cut it a lot.
That would be a useful avenue to explore. Unfortunately, we are on kind of a tight fuse here trying to get the next kernel release ready. At the moment we are in the mode of moving fixes from 2.4.21 to 2.6, and this is one such fix. I'd be willing to pursue both in parallel so that in a future release
we have gotten to page_table_lock reduction as well. Does that make sense at all?
(I just don't want to get bogged down in a 6-month effort here unless we can't avoid it.)
Quoted 11 lines
I recall from exchanges with Dave McCracken 18 months ago that the
page_table_lockis _almost_ unnecessary inrmap.c, should be possible to get avoid it there and in some other places.We take
page_table_lockwhen making absent present and when making present absent: I like your observation that those are exclusive cases.But you've found that narrowing the width of the
page_table_lockin a particular path does not help. You sound surprised, me too. Did you find out why that was?
See above comment.
Quoted 8 lines
Quoted 3 lines
- One could avoid pte locking by introducing a
pte_cmpxchg. cmpxchg seems to be supported by all ia64 and i386 cpus except the original 80386.I do think this will be a more fruitful direction than pte locking:
just looking through the arches for spare bits puts me off pte locking.
The original patch that we had for 2.4.21 did exactly that, we shied away from that due to concerns as to which processors allow you to update a running pte using a cmpxchg (== the set of processors for which set_pte() is a simple store.) AFAIK, the only such processor is i386, but if Christoph is correct, then more recent Intel x86 processors don't even have that restriction. I'll admit that I encouraged Christoph not to follow that path due to concerns of arch dependent code creeping into the do_anonymous_page() path.
Best Regards,
Ray
Quoted 3 lines · Hugh Dickins
Quoted 3 lines
Just handling that one anonymous case is not worth it, when we know that the next day someone else from SGI will post a similar test which shows the same on file pages ;)
Quoted 5 lines · Ray Bryant
Hugh -- this is called full employment for kernel scalability analysts. :-) :-)
Actually, disks are so slow that I wouldn't expect that scalability problem to show up in the page fault code, but rather in the block I/O or page cache management portions of the code instead.
mapping->tree_lock is a near-certain culprit-to-be.
Quoted 3 lines · Ray Bryant
I think that the major impact here is actually grabbing the lock when 30 or more processors are trying to obtain it -- the amount of time that the lock is actually held is insignificant in comparison.
The spinlocking algorithms in general use are rather weak. Queued locks with O(contenders) cacheline transfers instead of unbounded may be useful in such arrangements so that occasional contention is not so catastrophic, and it appears you certainly have the space for them. In general, everyone's favored rearranging algorithms for less contention instead of fiddling with locking algorithms, but I suspect in the case of such large systems the number of nontrivial algorithms to devise is daunting enough locking algorithms may mitigate the issues.
Quoted 3 lines · Hugh Dickins
Quoted 3 lines
The main lesson I took from your patch (I think wli was hinting at the same) is that we ought now to question
page_table_lockusage, should be possible to cut it a lot.
Quoted 9 lines · Ray Bryant
That would be a useful avenue to explore. Unfortunately, we are on kind of
a tight fuse here trying to get the next kernel release ready. At the
moment we are in the mode of moving fixes from 2.4.21 to 2.6, and this is
one such fix. I'd be willing to pursue both in parallel so that in a
future release
we have gotten topage_table_lockreduction as well. Does that make sense at all?
(I just don't want to get bogged down in a 6-month effort here unless we can't avoid it.)
Scalability issues with fault handling have trivial enough hardware requirements that it's likely feasible for others to work on it also. Also fortunate for you is that others also have issues here, and those on much smaller systems.
Quoted 2 lines · Hugh Dickins
Quoted 2 lines
I do think this will be a more fruitful direction than pte locking:
just looking through the arches for spare bits puts me off pte locking.
Quoted 8 lines · Ray Bryant
The original patch that we had for 2.4.21 did exactly that, we shied away from that due to concerns as to which processors allow you to update a running pte using a cmpxchg (= the set of processors for which
set_pte()is a simple store.) AFAIK, the only such processor is i386, but if Christoph is correct, then more recent Intel x86 processors don't even have that restriction. I'll admit that I encouraged Christoph not to follow that path due to concerns of arch dependent code creeping into thedo_anonymous_page()path.
I'm in general more concerned about how one synchronizes with TLB miss handlers, particularly for machines where this would involve the TLB miss handler looping until a valid value is fetched in what is now a very highly optimized performance-critical codepath.
-- wli