From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Mon, 16 Apr 2007 13:39:45 -0500 From: Anton Blanchard Subject: Re: [PATCH] make MADV_FREE lazily free memory Message-ID: <20070416183945.GA10067@kryten> References: <461C6452.1000706@redhat.com> <461D6413.6050605@cosmosbay.com> <461D67A9.5020509@redhat.com> <461DC75B.8040200@cosmosbay.com> <461DCCEB.70004@yahoo.com.au> <461DCDDA.2030502@yahoo.com.au> <461DDE44.2040409@redhat.com> <20070416161039.GA979@kryten> <20070416163057.GH355@devserv.devel.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070416163057.GH355@devserv.devel.redhat.com> Sender: owner-linux-mm@kvack.org Return-Path: To: Jakub Jelinek Cc: Rik van Riel , Nick Piggin , Eric Dumazet , linux-kernel , linux-mm , Ulrich Drepper List-ID: Hi Jakub, > That would mean an additional syscall. Furthermore, if you allocate a big > chunk of memory, dirty it, then free (with madvise (MADV_FREE)) it and soon > allocate the same size of memory again, it is better to start that with > non-dirty memory, it might be that this time you e.g. don't modify a big > part of the chunk. If all that memory was kept dirty all the time and > just marked/unmarked for lazy reuse with MADV_FREE/MADV_UNDO_FREE, all that > memory would need to be saved to disk when paging out as it was marked > dirty, while with current Rik's MADV_FREE that will happen only for pages > that were actually dirtied after the last malloc. Yep this all makes sense. I was looking at it from the other angle where on some workloads we have to force malloc to use brk for best performance. Im sure the MADV_FREE changes will close that gap but it would be interesting to see if there is still a gap on the problem workloads. Maybe Im worrying about nothing. Anton -- 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