On Mon, 1 Aug 2005, Paul Jackson wrote:
> In your related patch, you show how to merge this display of mempolicy
> into the new /proc/<pid>/smap (rss size of each memory area) file.
> But this smap file (or, as you renamed it, emap file) is read-only,
> so far as I can tell. It enables display of information, but not
> changing it. How do you propose to support changing a memory policy?
That is not clear yet. We need to discuss that. First I thought of just
having a patch that creates /proc/<pid>/numa_policy which allows
to read and write the process policy (write via notifier not directly).
> that other half should not also be used to display memory policies,
> instead of adapting smap aka emap.
e/smap is a generic way to get information about storage use of a vma.
Therefore displaying numa node information etc there makes a lot of
sense.
> Would it be better to have two files, the first of which has one of
> the strings:
Yes. I initially had something like that in mind and have a partial
implementation but such an approach gets extremely complicated and
difficult to handle since you need to create multiple
levels of directories in /proc/<pid>/xx. It is easier to obtain the
complete memory information from a single file. We already have that in
/proc/<pid>/maps.
-
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]
|
|