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

Christoph Lameter
2005-03-03T05:48:38Z

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\x110922543030922&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.