On Thu, May 03, 2007 at 01:39:37PM -0700, Stephane Eranian wrote: > 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
This is wrong. I have often used mlock as a normal user. Not sure where you got this, but it is valid for a normal user to be able to use mlock. Why else would there be an _USER_ limit? > the update yourself. Furthermore, we cannot afford to take page fault in > the PMU interrupt handler. You do not need to take any page faults in the PMU handler. While you are setting up the pages for sampling, call do_mlock from the kernel and you will get the pages locked. To ensure they are faulted, do get_user_pages(). That said, I think mlock at all is the wrong thing. Where did that code come from? > 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. So limit the sample buffer size using something reasonable. mlock is not the same as a shared buffer size. We are finding that on even small sized systems, your requirement would require us to increase the mlock limit for everything on the system in order to sample with the existing number of entries. For SuSE, the ulimit default is 128k. That is 8 pages on ia64. With the current algorithm, I am limited to 8 cpus before I exceed that limit. That is a tiny system and is _SIGNIFICANTLY_ below the old limit. On a completely seperate note, this entire calculation in user space is probably a bad idea. Why not let the kernel calculate the limit and return the failure. Don't require a similar calculation to be done in two seperate locations which just adds complexity that does not need to be there. Thanks, Robin _______________________________________________ perfmon mailing list [email protected] http://www.hpl.hp.com/hosted/linux/mail-archives/perfmon/
