Robin, On Thu, May 03, 2007 at 03:09:10PM -0500, Robin Holt wrote: > On Thu, May 03, 2007 at 09:51:10AM -0700, Stephane Eranian wrote: > > Tony, > > > > On Thu, May 03, 2007 at 11:35:48AM -0500, Tony Ernst wrote: > > > > allocation is successful. This is gone from v2.4 and also the v2.0 > > > > compatbility layer embedded in it for IA-64. > > > > > > > > I am willing to take your pfmon patch but I would also welcome a kernel > > > > patch to correctly manage RLIMIT_MEMLOCK for v2.0. > > > > > > I'm afraid I don't understand this comment. You don't want to update > > > RLIMIT_MEMLOCK.rlim_cur when you allocate. rlim_cur is your current > > > (soft) limit. It's not a running total of how much is left. Did you > > > mean mm->locked_vm? locked_vm is being updated in your latest patchset. > > > > > Yes, sorry, I meant locked_vm. It may not be updated in the v2.0. > > I am a little confused at how you got to using locked_vm? Shouldn't you > be using do_mlock() to lock the region of memory and letting the kernel > page fault handler update locked_vm? In the code, you mention a denial > of service issue. What is that issue? > Using mlock() requires root privileges. You do not want to restrict monitoring tools (using smapling) to root users. Thus you have to do the update yourself. Furthermore, we cannot afford to take page fault in the PMU interrupt handler.
The issue is with program which would request a very large buffer. Keep in mind that the sampling buffer is allocated by the kernel with vmalloc(). This is not user-pageable memory. -- -Stephane _______________________________________________ perfmon mailing list [email protected] http://www.hpl.hp.com/hosted/linux/mail-archives/perfmon/
