On Thu, 4 Aug 2005, Andi Kleen wrote:
> > There is this scan over the page table that verifies if all nodes are
> > allocated according to the policy. That scan could easily be used to
> > provide a map to the application (and to /proc/<pid>/smap) of where the
>
> The application can already get it. But it's an ugly feature
> that I only used for debugging and I was actually considering
> to remove it.
>
> Doing it for external users is a completely different thing though.
> I still think those have business in messing with other people's
> virtual addresses. In addition I expect it will cause problems
> longer term
> (did you ever look why mmap on /proc/*/mem is not allowed - it used
> to be long ago, but it was impossible to make it work race free and
> before that was always a gapping security hole)
The proc stuff is fake anyways. I would not worry about that. The biggest
worry is the locking mechanism to make this clean.
There are three possibilites:
1. do what cpusets is doing by versioning.
2. Have the task notifier access the task_struct information.
See http://lwn.net/Articles/145232/ "A new path to the refrigerator"
3. Maybe the easiest: Require mmap_sem to be taken for all policy
accesses. Currently its only require for vma policies. Then we need
to make a copy of the policy at some point so that alloc_pages can
access policy information lock free. This may also allow us to fix
the bind issue if we would f.e. keep a bitmap in the taskstruct or (ab)use
the cpusets map.
> If they cannot afford enough disk space it might be possible
> to do the page migration in swap cache like Hugh proposed.
This code already exist in the memory hotplug code base and Ray already
had a working implementation for page migration. The migration code will
also be necessary in order to relocate pages with ECC single bit failures
that Russ is working on (of course that will only work for some pages) and
for Mel Gorman's defragmentation approach (if we ever get the split into
differnet types of memory chunks in).
-
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]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |