From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758478Ab2GLAXi (ORCPT ); Wed, 11 Jul 2012 20:23:38 -0400 Received: from e31.co.us.ibm.com ([32.97.110.149]:51624 "EHLO e31.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755832Ab2GLAXg (ORCPT ); Wed, 11 Jul 2012 20:23:36 -0400 Message-ID: <4FFE18FF.6080307@linux.vnet.ibm.com> Date: Wed, 11 Jul 2012 19:23:27 -0500 From: Seth Jennings User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Nitin Gupta CC: Greg Kroah-Hartman , Andrew Morton , Dan Magenheimer , Konrad Rzeszutek Wilk , Minchan Kim , Robert Jennings , linux-mm@kvack.org, devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/4] zsmalloc: remove x86 dependency References: <1341263752-10210-1-git-send-email-sjenning@linux.vnet.ibm.com> <1341263752-10210-2-git-send-email-sjenning@linux.vnet.ibm.com> <4FFDC54F.5030402@vflare.org> <4FFDE2E2.7050901@linux.vnet.ibm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12071200-7282-0000-0000-00000AD3FB1F Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07/11/2012 05:42 PM, Nitin Gupta wrote: > On Wed, Jul 11, 2012 at 1:32 PM, Seth Jennings > wrote: >> On 07/11/2012 01:26 PM, Nitin Gupta wrote: >>> Now obj-1 lies completely within page-2, so can be kmap'ed as usual. On >>> zs_unmap_object() we would just do the reverse and restore objects as in >>> figure-1. >> >> Hey Nitin, thanks for the feedback. >> >> Correct me if I'm wrong, but it seems like you wouldn't be able to map >> ob2 while ob1 was mapped with this design. You'd need some sort of >> zspage level protection against concurrent object mappings. The >> code for that protection might cancel any benefit you would gain by >> doing it this way. >> > > Do you think blocking access of just one particular object (or > blocking an entire zspage, for simplicity) for a short time would be > an issue, apart from the complexity of implementing per zspage > locking? It would only need to prevent the mapping of the temporarily displaced object, but I said zspage because I don't know how we would do per-object locking. I actually don't know how we would do zspage locking either unless there is a lock in the struct page we can use. Either way, I think it is a complexity I think we'd be better to avoid for now. I'm trying to get zsmalloc in shape to bring into mainline, so I'm really focusing on portability first and low hanging performance fruit second. This optimization would be more like top-of-the-tree performance fruit :-/ However, if you want to try it out, don't let me stop you :) Thanks, Seth From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx144.postini.com [74.125.245.144]) by kanga.kvack.org (Postfix) with SMTP id 288F46B005D for ; Wed, 11 Jul 2012 20:25:08 -0400 (EDT) Received: from /spool/local by e38.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 11 Jul 2012 18:25:07 -0600 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by d03dlp03.boulder.ibm.com (Postfix) with ESMTP id 6BB1719D804A for ; Thu, 12 Jul 2012 00:24:28 +0000 (WET) Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q6C0NkUd006308 for ; Wed, 11 Jul 2012 18:24:03 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q6C0NUQs024844 for ; Wed, 11 Jul 2012 18:23:30 -0600 Message-ID: <4FFE18FF.6080307@linux.vnet.ibm.com> Date: Wed, 11 Jul 2012 19:23:27 -0500 From: Seth Jennings MIME-Version: 1.0 Subject: Re: [PATCH 1/4] zsmalloc: remove x86 dependency References: <1341263752-10210-1-git-send-email-sjenning@linux.vnet.ibm.com> <1341263752-10210-2-git-send-email-sjenning@linux.vnet.ibm.com> <4FFDC54F.5030402@vflare.org> <4FFDE2E2.7050901@linux.vnet.ibm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Nitin Gupta Cc: Greg Kroah-Hartman , Andrew Morton , Dan Magenheimer , Konrad Rzeszutek Wilk , Minchan Kim , Robert Jennings , linux-mm@kvack.org, devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org On 07/11/2012 05:42 PM, Nitin Gupta wrote: > On Wed, Jul 11, 2012 at 1:32 PM, Seth Jennings > wrote: >> On 07/11/2012 01:26 PM, Nitin Gupta wrote: >>> Now obj-1 lies completely within page-2, so can be kmap'ed as usual. On >>> zs_unmap_object() we would just do the reverse and restore objects as in >>> figure-1. >> >> Hey Nitin, thanks for the feedback. >> >> Correct me if I'm wrong, but it seems like you wouldn't be able to map >> ob2 while ob1 was mapped with this design. You'd need some sort of >> zspage level protection against concurrent object mappings. The >> code for that protection might cancel any benefit you would gain by >> doing it this way. >> > > Do you think blocking access of just one particular object (or > blocking an entire zspage, for simplicity) for a short time would be > an issue, apart from the complexity of implementing per zspage > locking? It would only need to prevent the mapping of the temporarily displaced object, but I said zspage because I don't know how we would do per-object locking. I actually don't know how we would do zspage locking either unless there is a lock in the struct page we can use. Either way, I think it is a complexity I think we'd be better to avoid for now. I'm trying to get zsmalloc in shape to bring into mainline, so I'm really focusing on portability first and low hanging performance fruit second. This optimization would be more like top-of-the-tree performance fruit :-/ However, if you want to try it out, don't let me stop you :) Thanks, Seth -- 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