From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1767198AbXDESil (ORCPT ); Thu, 5 Apr 2007 14:38:41 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1767200AbXDESil (ORCPT ); Thu, 5 Apr 2007 14:38:41 -0400 Received: from mx1.redhat.com ([66.187.233.31]:59224 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1767198AbXDESij (ORCPT ); Thu, 5 Apr 2007 14:38:39 -0400 Message-ID: <46154226.6080300@redhat.com> Date: Thu, 05 Apr 2007 14:38:30 -0400 From: Rik van Riel Organization: Red Hat, Inc User-Agent: Thunderbird 1.5.0.7 (X11/20061008) MIME-Version: 1.0 To: Nick Piggin CC: Ulrich Drepper , Andrew Morton , Linux Kernel , Jakub Jelinek , Linux Memory Management Subject: Re: missing madvise functionality References: <46128051.9000609@redhat.com> <461357C4.4010403@yahoo.com.au> In-Reply-To: <461357C4.4010403@yahoo.com.au> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Nick Piggin wrote: > Oh, also: something like this patch would help out MADV_DONTNEED, as it > means it can run concurrently with page faults. I think the locking will > work (but needs forward porting). Ironically, your patch decreases throughput on my quad core test system, with Jakub's test case. MADV_DONTNEED, my patch, 10000 loops (14k context switches/second) real 0m34.890s user 0m17.256s sys 0m29.797s MADV_DONTNEED, my patch & your patch, 10000 loops (50 context switches/second) real 1m8.321s user 0m20.840s sys 1m55.677s I suspect it's moving the contention onto the page table lock, in zap_pte_range(). I guess that the thread private memory areas must be living right next to each other, in the same page table lock regions :) For more real world workloads, like the MySQL sysbench one, I still suspect that your patch would improve things. Time to move back to debugging other stuff, though. Andrew, it would be nice if our patches could cook in -mm for a while. Want me to change anything before submitting? -- Politics is the struggle between those who want to make their country the best in the world, and those who believe it already is. Each group calls the other unpatriotic. From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <46154226.6080300@redhat.com> Date: Thu, 05 Apr 2007 14:38:30 -0400 From: Rik van Riel MIME-Version: 1.0 Subject: Re: missing madvise functionality References: <46128051.9000609@redhat.com> <461357C4.4010403@yahoo.com.au> In-Reply-To: <461357C4.4010403@yahoo.com.au> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org Return-Path: To: Nick Piggin Cc: Ulrich Drepper , Andrew Morton , Linux Kernel , Jakub Jelinek , Linux Memory Management List-ID: Nick Piggin wrote: > Oh, also: something like this patch would help out MADV_DONTNEED, as it > means it can run concurrently with page faults. I think the locking will > work (but needs forward porting). Ironically, your patch decreases throughput on my quad core test system, with Jakub's test case. MADV_DONTNEED, my patch, 10000 loops (14k context switches/second) real 0m34.890s user 0m17.256s sys 0m29.797s MADV_DONTNEED, my patch & your patch, 10000 loops (50 context switches/second) real 1m8.321s user 0m20.840s sys 1m55.677s I suspect it's moving the contention onto the page table lock, in zap_pte_range(). I guess that the thread private memory areas must be living right next to each other, in the same page table lock regions :) For more real world workloads, like the MySQL sysbench one, I still suspect that your patch would improve things. Time to move back to debugging other stuff, though. Andrew, it would be nice if our patches could cook in -mm for a while. Want me to change anything before submitting? -- Politics is the struggle between those who want to make their country the best in the world, and those who believe it already is. Each group calls the other unpatriotic. -- 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