On Tue, 1 Aug 2006, Chris Wright wrote:
* Ian Wienand ([email protected]) wrote:
On Tue, Aug 01, 2006 at 10:18:33PM -0700, Christoph Lameter wrote:
I have not been involved in this issue for a long time now.
You need to contact the people actively working on code like this.
Most important is likely Ian Wienand.
Paul Davies <[email protected]> is the person actively working
on this project. I might note he has not been doing it un-announced;
see
http://marc.theaimsgroup.com/?l=linux-mm&m=115276500100695&w=2
for the latest patches, or some of the other links Cristoph pointed
out. I'm sure he'd love to talk to anyone about it :)
Well that looks closer to the iterator here than some of the eariler
links. The apply_to_page_range is pretty trivial, will have to look at
Paul's patches to see if there's something we can use. This is just for
Xen's use ATM, so we can always revert to keeping it Xen local if Paul's
changes are heading upstream, and use them once they're in.
thanks,
-chris
Hi Chris
I understand you are looking for a generic iterator to operate on a set
of ptes within a given address range.
Unfortunately just about every iteration in the kernel now varies slightly
(usually at the pte directory level) in such a way that abstracting out
each iteration into generic iterators becomes somewhat problematic.
I classify them into read, build and dual iterators.
READ iterators: read a page table within a range and operate on the ptes
eg: unmap_page_range, change protection, msync ...
BUILD iterators: build a page table in a range while operating on the
ptes.
eg: vmap_pte_range, remap_pfn_range, ...
DUAL iterators: read and build a page table within a range and operate on
the ptes.
eg: copy_page_range (src and dst page tables different)
eg: mremap iterator (src and dst page tables the same)
A little over a year ago it was possible to abstract the iterators
into these classes because they were relatively untailored. During the
last year a fair bit of customisation has occured on many iterators and
some additional iterations added. Some of these iterators are performance
critical and their tailoring necessary. The ones that are less important
would need to be tidied up so that abstraction to generic iterators can
occur.
Because of the continual divergence of the iterators I have removed the
generic iterators where I would pass it a function across the interface
because they became too unweildy.
One possible solution is to have a set of critical and non critical
iterators. The non critical iterators would comprise a generic read and
build iterator.
However at this stage the Linux community seems relatively content to
access the page table data structure in an open fashion with tailored cut
and paste iterators. This method does have its advantages but it makes
changing the page table implementation more difficult.
Cheers
Paul Davies
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
