Prev: Who should I discuss with about framebuffer issues?
Next: linux-next: build warnings after merge of the driver-core tree
From: Michel Lespinasse on 20 May 2010 22:50 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 21 May 2010 21:50
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/ |