From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757642AbYBKSPs (ORCPT ); Mon, 11 Feb 2008 13:15:48 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754999AbYBKSPj (ORCPT ); Mon, 11 Feb 2008 13:15:39 -0500 Received: from sca-es-mail-1.Sun.COM ([192.18.43.132]:46302 "EHLO sca-es-mail-1.sun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754493AbYBKSPh (ORCPT ); Mon, 11 Feb 2008 13:15:37 -0500 Date: Mon, 11 Feb 2008 11:15:26 -0700 From: Andreas Dilger Subject: Re: [sample] mem_notify v6: usage example In-reply-to: <2f11576a0802090846t7655e988pb1b712696cad1098@mail.gmail.com> To: KOSAKI Motohiro Cc: Jon Masters , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Marcelo Tosatti , Daniel Spang , Rik van Riel , Andrew Morton , Alan Cox , "linux-fsdevel@vger.kernel.org" , Pavel Machek , Al Boldi , Zan Lynx Message-id: <20080211181526.GC3029@webber.adilger.int> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-GPG-Key: 1024D/0D35BED6 X-GPG-Fingerprint: 7A37 5D79 BF1B CECA D44F 8A29 A488 39F5 0D35 BED6 References: <2f11576a0802090755n123c9b7dh26e0af6a2fef28af@mail.gmail.com> <2f11576a0802090846t7655e988pb1b712696cad1098@mail.gmail.com> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Feb 10, 2008 01:46 +0900, KOSAKI Motohiro wrote: > > This really needs to be triggered via a generic kernel event in the > > final version - I picture glibc having a reservation API and having > > generic support for freeing such reservations. > > to be honest, I doubt idea of generic reservation framework. > > end up, we hope drop the application cache, not also dataless memory. > but, automatically drop mechanism only able to drop dataless memory. > > and, many application have own memory management subsystem. > I afraid to nobody use too complex framework. Having such notification handled by glibc to free up unused malloc (or any heap allocations) would be very useful, because even if a program does "free" there is no guarantee the memory is returned to the kernel. I think that having a generic reservation framework is too complex, but hiding the details of /dev/mem_notify from applications is desirable. A simple wrapper (possibly part of glibc) to return the poll fd, or set up the signal is enough. Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc. From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Mon, 11 Feb 2008 11:15:26 -0700 From: Andreas Dilger Subject: Re: [sample] mem_notify v6: usage example In-reply-to: <2f11576a0802090846t7655e988pb1b712696cad1098@mail.gmail.com> Message-id: <20080211181526.GC3029@webber.adilger.int> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <2f11576a0802090755n123c9b7dh26e0af6a2fef28af@mail.gmail.com> <2f11576a0802090846t7655e988pb1b712696cad1098@mail.gmail.com> Sender: owner-linux-mm@kvack.org Return-Path: To: KOSAKI Motohiro Cc: Jon Masters , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Marcelo Tosatti , Daniel Spang , Rik van Riel , Andrew Morton , Alan Cox , "linux-fsdevel@vger.kernel.org" , Pavel Machek , Al Boldi , Zan Lynx List-ID: On Feb 10, 2008 01:46 +0900, KOSAKI Motohiro wrote: > > This really needs to be triggered via a generic kernel event in the > > final version - I picture glibc having a reservation API and having > > generic support for freeing such reservations. > > to be honest, I doubt idea of generic reservation framework. > > end up, we hope drop the application cache, not also dataless memory. > but, automatically drop mechanism only able to drop dataless memory. > > and, many application have own memory management subsystem. > I afraid to nobody use too complex framework. Having such notification handled by glibc to free up unused malloc (or any heap allocations) would be very useful, because even if a program does "free" there is no guarantee the memory is returned to the kernel. I think that having a generic reservation framework is too complex, but hiding the details of /dev/mem_notify from applications is desirable. A simple wrapper (possibly part of glibc) to return the poll fd, or set up the signal is enough. Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org