[lkml]   [2002]   [Jul]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch 1/13] misc fixes
On Sunday 28 July 2002 09:32, Andrew Morton wrote:
> We have some fairly serious locking contention problems with the reverse
> mapping's pte_chains. Until we have a clear way out of that I believe
> that it is best to not merge code which has a lot of rmap dependency.
> It is apparent that these problems will not be solved by tweaking -
> some redesign is needed. In the 2.5 timeframe the only practical
> solution appears to be page table sharing, based on Daniel's February
> work. Daniel and Dave McCracken are working that.

Sadly, it turns out that there are no possibilities for page table sharing
when forking from bash. It turns out there are only about 200 pages being
shared amonst three page tables (stack, text and .interp) and at least one
page in each of these gets written during the exec, so all are unshared and
hence there is no reduction in the number of pte chains that have to be
created. For forking from a larger parent, page table sharing has a
measurable benefit, but not from these little guys.

But there is something massively wrong with this whole picture. Your kickass
4 way is managing to set up and tear down only one pte chain node per
microsecond, if I'm reading your benchmark results correctly. That's really
horrible. I think we need to revisit the locking.

The idea I'm playing with now is to address an array of locks based on
something like:

spin_lock(pte_chain_locks + ((page->index >> 4) & 0xff));

so that 16 consecutive filemap pages use the same lock and there is a limited
total number of locks to keep cache pressure down. Since we are creating the
vast majority of the pte chain nodes while walking across page tables, this
should give nice locality.

For this to work, anon pages will need to have something in page->index.
This isn't too much of a challenge. A reasonable value to put in there is
the creator's virtual address, shifted right, and perhaps mangled a little to
reduce contention.

We can also look at batching the pte chain node creation by preallocating 16
nodes, taking the lock, and walking through the 16 nodes filling in the
pointers. If the page index changes to a different lock we drop the one we
have and acquire the new one.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:27    [W:0.078 / U:24.936 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site