On Tuesday 07 May 2002 21:50, William Lee Irwin III wrote:

quoted

Generally the way to achieve this is by anticipating those bulk
operations and providing standardized methods for them. copy_page_range()
and zap_page_range() are already examples of this. For other cases,
it's perhaps a useful layer inversion.

On Wed, May 08, 2002 at 01:02:02AM +0200, Daniel Phillips wrote:

What I'm really talking about is how you'd reimplement copy_page_range,
zap_page_range, and the other 4-5 primitives that use the 3 nested loops
style of traversing the i86-style page table structure.

Why reimplement when you can rename? =)

These guys aren't really the culprits. By and large the pagetables are
just overused and overexposed; things that aren't speed critical should
probably just pass callbacks into a generic walker if they absolutely
have to walk pagetables. i.e. if you aren't the VM, don't do this.
Walking pagetables is horribly slow anyway, zap_page_range() has
ridiculous latencies. Shoving these guys off into their own module
would likely be enough for the moment.


Cheers,
Bill
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/