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 Content-Length: 1374 Lines: 33 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 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/