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

[Christoph Lameter]

On Wed, 2 Mar 2005, Andrew Morton wrote:

> > There should be no change to these arches
>
> But we must at least confirm that these architectures can make these
> changes in the future.  If they make no changes then they haven't
> benefitted from the patch.  And the patch must be suitable for all
> architectures which might hit this scalability problem.
>
> > Could we at least get the first two patches in? I can then gradually
> > address the other issues piece by piece.
>
> The atomic ops patch should be coupled with the main patch series.  The mm
> counter one we could sneak in beforehand, I guess.

The atomic ops patch basically just avoids doing a pte_clear and then
setting the pte for archs that define CONFIG_ATOMIC_TABLE_OPS. This is
unecessary on ia64 and ia32 AFAIK.

>
> > The necessary more sweeping design change can be found at
> >
> > http://marc.theaimsgroup.com/?l=linux-kernel&m=110922543030922&w=2
> >
> > but these may be a long way off.
>
> Yes, that seemed sensible, although it may not work out to be as clean as
> it appears.

Of course. But at least we would like to start as clean as possible.

> But how would that work allow us to address page_table_lock scalability
> problems?

Because the actual locking method is abstracted in a transaction
(idea by Nick Piggins, I just tried to make it cleaner). The arch may use
pte locking, pmd locking, atomic ops or whatever to provide
synchronization for page table operations.


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