Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753288Ab0AGQh1 (ORCPT ); Thu, 7 Jan 2010 11:37:27 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753086Ab0AGQh0 (ORCPT ); Thu, 7 Jan 2010 11:37:26 -0500 Received: from nlpi157.sbcis.sbc.com ([207.115.36.171]:36001 "EHLO nlpi157.prodigy.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752956Ab0AGQhZ (ORCPT ); Thu, 7 Jan 2010 11:37:25 -0500 Date: Thu, 7 Jan 2010 10:36:52 -0600 (CST) From: Christoph Lameter X-X-Sender: cl@router.home To: Linus Torvalds cc: Arjan van de Ven , Peter Zijlstra , "Paul E. McKenney" , Peter Zijlstra , KAMEZAWA Hiroyuki , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "minchan.kim@gmail.com" , "hugh.dickins" , Nick Piggin , Ingo Molnar Subject: Re: [RFC][PATCH 6/8] mm: handle_speculative_fault() In-Reply-To: Message-ID: References: <20100104182429.833180340@chello.nl> <20100104182813.753545361@chello.nl> <20100105054536.44bf8002@infradead.org> <20100105192243.1d6b2213@infradead.org> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1580 Lines: 32 On Thu, 7 Jan 2010, Linus Torvalds wrote: > You're missing what Arjan said - the jav workload does a lot of memory > allocations too, causing mmap/munmap. Well isnt that tunable on the app level? Get bigger chunks of memory in order to reduce the frequency of mmap operations? If you want concurrency of faults then mmap_sem write locking currently needs to be limited. > So now some paths are indeed holding it for writing (or need to wait for > it to become writable). And the fairness of rwsems quite possibly then > impacts throughput a _lot_.. Very true. Doing range locking (maybe using the split pte lock boundaries, shifting some state from mm_struct into vmas) may be a way to avoid hold mmap_sem for write in that case. > (Side note: I wonder if we should wake up _all_ readers when we wake up > any. Right now, we wake up all readers - but only until we hit a writer. > Which is the _fair_ thing to do, but it does mean that we can end up in > horrible patterns of alternating readers/writers, when it could be much > better to just say "release the hounds" and let all pending readers go > after a writer has had its turn). Have a cycle with concurrent readers followed by a cycle of serialized writers may be best under heavy load. The writers need to be limited in frequency otherwise they will starve the readers. -- 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/