Re: Hugh's alternate page fault scalability approach on 512p Altix

["Martin J. Bligh" <mbligh@mbligh.org>]

>> > Anticipatory prefaulting raises the highest fault rate obtainable three-fold
>> > through gang scheduling faults but may allocate some pages to a task that are
>> > not needed.
>> 
>> IIRC that costed more than it saved, at least for forky workloads like a
>> kernel compile - extra cost in zap_pte_range etc. If things have changed
>> substantially in that path, I guess we could run the numbers again - has
>> been a couple of years.
> 
> Right. The costs come about through wrong anticipations installing useless 
> mappings. The patches that I posted have this feature off by default. Gang 
> scheduling can be enabled by modifying a value in /proc. But I guess the 
> approach is essentially dead unless others want this feature too. The 
> current page fault scalability approach should be fine for a couple of 
> years and who knows what direction mmu technology has taken then.

It would seem to depends on the locality of reference in the affected files.
Which implies to me that the locality of libc, etc probably sucks, though
we had a simple debug patch somewhere to print out a bitmap of which pages
are faulted in and which are not ... was somewhere, I'll see if I can find
it.

M.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/