Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261274AbVDYWvl (ORCPT ); Mon, 25 Apr 2005 18:51:41 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261277AbVDYWvk (ORCPT ); Mon, 25 Apr 2005 18:51:40 -0400 Received: from fmr19.intel.com ([134.134.136.18]:41373 "EHLO orsfmr004.jf.intel.com") by vger.kernel.org with ESMTP id S261274AbVDYWvW (ORCPT ); Mon, 25 Apr 2005 18:51:22 -0400 From: "Bob Woodruff" To: "'Andrew Morton'" , "Timur Tabi" , "Davis, Arlin R" Cc: , , Subject: RE: [openib-general] Re: [PATCH][RFC][0/4] InfiniBand userspace verbsimplementation Date: Mon, 25 Apr 2005 15:51:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcVJ5zR+UqmxlNOHTZ6BgvvwWxsZngAAD5MA In-Reply-To: <20050425153542.70197e6a.akpm@osdl.org> Message-ID: X-OriginalArrivalTime: 25 Apr 2005 22:51:04.0840 (UTC) FILETIME=[42E46880:01C549E9] Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1429 Lines: 32 Andrew Morton wrote, >Yes, we expect that all the pages which get_user_pages() pinned will become >unpinned within the context of the syscall which pinned the pages. Or >shortly after, in the case of async I/O. >This is because there is no file descriptor or anything else associated >with the pages which permits the kernel to clean stuff up on unclean >application exit. Also there are the obvious issues with permitting >pinning of unbounded amounts of memory. There definitely needs to be a mechanism to prevent people from pinning too much memory. We saw issues in the sourceforge stack and some of the vendors stacks where we could lock memory till the system hung. In the sourceforge InfiniBand stack, we put in a check to make sure that people did not pin too much memory. It was sort of a crude/bruit force mechanism, but effective. I think that we limited people from locking down more that 1/2 of kernel memory or 70 % of all memory (it was tunable with a module option) and if they exceeded the limit, their requests to register memory would begin to fail. Arlin can provide details on how we did it or people can look at the IBAL code for an example. woody - 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/