From: Michel Lespinasse on
On Wed, May 19, 2010 at 8:21 AM, David Howells <dhowells(a)redhat.com> wrote:
> �0 � 0 �10 � 2 � 1 s � 2/2 � � � � 0 � � � � 0 � 2217200 � �636227 � �210255
> �0 � 0 �10 � 2 � 1 s � 2/2 � � � � 0 � � � � 0 � 2217903 � �629175 � �212926
> �0 � 0 �10 � 2 � 1 s � 2/2 � � � � 0 � � � � 0 � 2224136 � �647912 � �212506
>
> Feel free to have a play.

Thanks for sharing your testing code.

> BTW, the code also works on FRV in NOMMU mode (which uses the spinlock-based
> rwsem version).

Yes, I made sure to keep the generic (and non-x86 asm) versions
working by always separating x86 specific changes from the rest.

> However... �I'm not certain that giving a process that's accessing
> /proc/pid/maps priority over a second process that may be trying to do mmap or
> page fault or something internally is a good idea.

One thing to keep in mind if you're concerned about the higher
priority is that these /proc files are still not open to everyone - a
user can't read the /proc/<pid>/exe and /proc/<pid>/maps files for
another user's processes unless he's got CAP_SYS_PTRACE priviledges.

--
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Michel Lespinasse on
On Wed, May 19, 2010 at 8:21 AM, David Howells <dhowells(a)redhat.com> wrote:
> However... �I'm not certain that giving a process that's accessing
> /proc/pid/maps priority over a second process that may be trying to do mmap or
> page fault or something internally is a good idea.
>
> It would be useful if you made clearer what you're actually measuring from
> /proc/pid/maps...

This is relatively large software; I don't actually have a complete
view of it myself.
However some of the things it does include the following:

- The cluster management software tracks ownership of sysv shm
segments, potentially deleting them if they have been abandoned.
/proc/<pid>/maps files are used as an input to these decisions.

- There is a separate module making numa aware decisions based on
/proc/<pid>/numa_maps information. This drives decisions such as
moving data between nodes (we have not been pushing the corresponding
kernel patches yet). Using down_read_critical() here would be
desirable too, but not as critical as for other parts of the system
(numa awareness is not the biggest worry when machines get under
enough memory pressure that reading numa_maps starts blocking).

--
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/