Messages in this thread | | | Date | Sun, 14 Mar 2004 00:48:25 -0800 | From | William Lee Irwin III <> | Subject | Re: [Lse-tech] Re: Hugetlbpages in very large memory machines....... |
| |
On Sun, Mar 14, 2004 at 02:38:33AM -0600, Ray Bryant wrote: > write mode and the mm->page_table_lock. So not only does it take 500 s for > the mmap() to return on our test system, but ps, top, etc all freeze for the > duration. Very irritating, especially on a 64 or 128 P system. > My preference would be to do away with bugetlb_prefault() altogether. > (If there was a MAP_NO_PREFAULT, we would have to make this the default on > Altix to avoid the freeze problem mentioned above. Can't have an arbitrary > user locking up the system.) As Andi pointed out, perhaps we can do some > prereservation of huge pages so that we can return a ENONMEM to the mmap() > if there are not enough huge pages to (lazily) be allocated to satisfy the > request, but then still allocate the pages at fault time. A simple count > would suffice.
There is a patch which arranges to keep statistics ready in the mm so that the mmap_sem need not be taken for /proc/ and furthermore renders proc_pid_statm() nothing more than copying integers out of the mm that I forward ported to 2.6.0-test*, originally by Ben LaHaise, that may also be of interest to those concerned about tripping over other processes' mmap_sem's in /proc/.
-- wli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |