Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752738Ab3EPPb7 (ORCPT ); Thu, 16 May 2013 11:31:59 -0400 Received: from mx1.redhat.com ([209.132.183.28]:24004 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751953Ab3EPPb6 (ORCPT ); Thu, 16 May 2013 11:31:58 -0400 Message-ID: <5194FB84.3000409@redhat.com> Date: Thu, 16 May 2013 11:30:12 -0400 From: Rik van Riel User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130402 Thunderbird/17.0.5 MIME-Version: 1.0 To: Seth Jennings CC: Dan Magenheimer , Andrew Morton , Greg Kroah-Hartman , Nitin Gupta , Minchan Kim , Konrad Rzeszutek Wilk , Robert Jennings , Jenifer Hopper , Mel Gorman , Johannes Weiner , Larry Woodman , Benjamin Herrenschmidt , Dave Hansen , Joe Perches , Joonsoo Kim , Cody P Schafer , Hugh Dickens , Paul Mackerras , linux-mm@kvack.org, linux-kernel@vger.kernel.org, devel@driverdev.osuosl.org Subject: Re: [PATCHv11 2/4] zbud: add to mm/ References: <1368448803-2089-1-git-send-email-sjenning@linux.vnet.ibm.com> <1368448803-2089-3-git-send-email-sjenning@linux.vnet.ibm.com> <3dfa0c20-ab39-4839-aaeb-46d51314afd4@default> <20130513205927.GA19183@medulla> In-Reply-To: <20130513205927.GA19183@medulla> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2129 Lines: 52 On 05/13/2013 04:59 PM, Seth Jennings wrote: > On Mon, May 13, 2013 at 08:43:36AM -0700, Dan Magenheimer wrote: >> The above appears to be a new addition to my original zbud design. >> While it may appear to be a good idea for improving LRU-ness, I >> suspect it may have unexpected side effects in that I think far >> fewer "fat" zpages will be buddied, which will result in many more >> unbuddied pages containing a single fat zpage, which means much worse >> overall density on many workloads. > > Yes, I see what you are saying. While I can't think of a workload that would > cause this kind of allocation pattern in practice, I also don't have a way to > measure the impact this first-fit fast path code has on density. > >> >> This may not be apparent in kernbench or specjbb or any workload >> where the vast majority of zpages compress to less than PAGE_SIZE/2, >> but for a zsize distribution that is symmetric or "skews fat", >> it may become very apparent. > > I'd personally think it should be kept because 1) it makes a fast allocation > path and 2) improves LRU locality. But, without numbers to demonstrate a > performance improvements or impacts on density, I wouldn't be opposed to taking > it out if it is a point of contention. > > Anyone else care to weigh in? I have no idea how much the "LRU-ness" of the compressed swap cache matters, since the entire thing will be full of not recently used data. I can certainly see Dan's point too, but there simply is not enough data to measure this. Would it be an idea to merge this patch, and then send a follow-up patch that: 1) makes this optimization a (debugfs) tunable, and 2) exports statistics on how well pages are packing That way we would be able to figure out which way should be the default. I'm giving the patch my Acked-by, because I want this code to finally move forward. -- All rights reversed -- 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/