Re: Page fault scalability patch V18: Drop first acquisition of ptl

[Christoph Lameter]

On Wed, 2 Mar 2005, Andrew Morton wrote:

> > There have been extensive discussions on all aspects of this patch.
> > This issue was discussed in
> > http://marc.theaimsgroup.com/?t=110694497200004&r=1&w=2
>
> This is a difficult, intrusive and controversial patch.  Things like the
> above should be done in a separate patch.  Not only does this aid
> maintainability, it also allows the change to be performance tested in
> isolation.

Well it would have been great if this was mentioned in the actual
discussion at the time.

> > The cmpxchg will fail if that happens.
>
> How about if someone does remap_file_pages() against that virtual address
> and that syscalls happens to pick the same physical page?  We have the same
> physical page at the same pte slot with different contents, and the cmpxchg
> will succeed.

Any mmap changes requires the mmapsem.

> > http://marc.theaimsgroup.com/?l=linux-kernel&m=110272296503539&w=2
>
> Those are different cases.  I still don't see why the change is justified in
> do_swap_page().

Lets undo that then.

> > These architectures have the atomic pte's not enable.  It would require
> > them to submit a patch to activate atomic pte's for these architectures.
>
>
> But if the approach which these patches take is not suitable for these
> architectures then they have no solution to the scalability problem.  The
> machines will perform suboptimally and more (perhaps conflicting)
> development will be needed.

They can implement their own approach with the provided hooks. You could
for example use SSE / MMX for atomic 64 bit ops on i386 with PAE mode by
using the start/stop macros to deal with the floatingh point issues.

> > One
> > would have to check for the lock being active leading to significant code
> > changes.
>
> Why?

Because if a pte is locked it should not be used.

Look this is an endless discussion with new things brought up at every
corner and I have reworked the patches numerous times. Could you tell me
some step by step way that we can finally deal with this? Specify a
sequence of patches and I will submit them to you step by step.

-
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/