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/