Received: by 10.213.65.68 with SMTP id h4csp1346599imn; Wed, 21 Mar 2018 08:30:02 -0700 (PDT) X-Google-Smtp-Source: AG47ELv0boi4lLA1Fo1Cs/Hlw3cCvnN5rxbojpPZmyUWHBtaevsMe9ig/sQnhi64FYPvRljcvgR5 X-Received: by 10.101.64.139 with SMTP id t11mr3425209pgp.119.1521646202172; Wed, 21 Mar 2018 08:30:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521646202; cv=none; d=google.com; s=arc-20160816; b=a1Mo7KMbVgIFNwi3um3f+JYpNVhl+zjuy0c+KIu0VRiaeD+C18kbTbGP0wCJWzWeCs RvEzKaTbsYyxpUF9+d51SvZQokMHVblmkgShcWRAusqIONDbNjKPxbt9Lgx4jZXxsGB0 eO4Gh179dnbYsLE9F3ny1VTxgzu73BEVVI9VADLQ6s6kM/HiRWQomrTzCR3iKWGNC51T bzwrRCszNsalKUPBPU7JVcLyjTwkty6GgJputxih0PMX8gIVs9c7wNMtHVCNFbo4cGqQ luo78qsM3JvvyOJpQkk+YiXmVQxzvEiaFQfwLHPB0+Ej+RBUIUefEx547O5eTV6Wm3Uo +Y9Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=ppRD6rtH0CmZBt6xHwZhH593wUeDu2hs5MjRXyFfOvg=; b=U03phM23WBY+MVqY/xZVM9/B6QTF69Nhcz1G3av27dhx/XNtBwbrfZweEZaInkgC+Q NMLc+wA3pb6vEVYzs38hHiQSTHEfIOGISfD9J61K5qa1gCqqc9ls+064RQqAI2flGkL8 ZU9d6sCPzdkxLSZv52hMbE/bC2X5D/75DEF/qWT9HsWubE7Wru+x+cnE7lOqIxUZS4Mt ogDLcQ85ZTKAvWWoucj14sKwRBRe1Pps/qq9veitGpz4QDRcwTZ7Mm+PJ+cmU2nlu9cZ d/T1a2djoRKqH83qQWOvoPLHMVTorwhUYyE4oBOZ/WTOAWbdppyLwyKx4qHEBoqZSdNk HGfA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=lVsmUsik; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 75si3168534pfp.353.2018.03.21.08.29.48; Wed, 21 Mar 2018 08:30:02 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=lVsmUsik; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752739AbeCUP1S (ORCPT + 99 others); Wed, 21 Mar 2018 11:27:18 -0400 Received: from bombadil.infradead.org ([198.137.202.133]:44104 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752732AbeCUP1O (ORCPT ); Wed, 21 Mar 2018 11:27:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ppRD6rtH0CmZBt6xHwZhH593wUeDu2hs5MjRXyFfOvg=; b=lVsmUsikkgKoqBouyMcdAMfIc 42oSOWQnQXszRfLQ+r+PeIWD/XCDpbcNmVvJ4Mwc93ZjJnID2C0iVhRngjVBp6Ig5MmXivtVsI2bL +0Cptz8pgwp46D4aDh3LFBjxK3NI95Nm5iRVnIvZztLr6oG8l/QLCjKMsjFcscSXBf0IekmlfxoRE sNZG8s4Dr8PuhN95D0yuUJrklZRxUtNu3yabwt4mX9GE4/uhAstPPxTZPoAPyVsV7URuxt8jH/bBx FVShC63EfMpD6NbJYiF7u6OXs/wxQKwh7DOkfaSVvbQJ0h0yOn+cD2byWYlKTLL8GoONeGRc6yQGx KukieItRg==; Received: from willy by bombadil.infradead.org with local (Exim 4.90_1 #2 (Red Hat Linux)) id 1eyfdY-0002Fz-2l; Wed, 21 Mar 2018 15:26:48 +0000 Date: Wed, 21 Mar 2018 08:26:47 -0700 From: Matthew Wilcox To: Kirill Tkhai Cc: viro@zeniv.linux.org.uk, hannes@cmpxchg.org, mhocko@kernel.org, vdavydov.dev@gmail.com, akpm@linux-foundation.org, tglx@linutronix.de, pombredanne@nexb.com, stummala@codeaurora.org, gregkh@linuxfoundation.org, sfr@canb.auug.org.au, guro@fb.com, mka@chromium.org, penguin-kernel@I-love.SAKURA.ne.jp, chris@chris-wilson.co.uk, longman@redhat.com, minchan@kernel.org, hillf.zj@alibaba-inc.com, ying.huang@intel.com, mgorman@techsingularity.net, shakeelb@google.com, jbacik@fb.com, linux@roeck-us.net, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 03/10] mm: Assign memcg-aware shrinkers bitmap to memcg Message-ID: <20180321152647.GB4780@bombadil.infradead.org> References: <152163840790.21546.980703278415599202.stgit@localhost.localdomain> <152163850081.21546.6969747084834474733.stgit@localhost.localdomain> <20180321145625.GA4780@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 21, 2018 at 06:12:17PM +0300, Kirill Tkhai wrote: > On 21.03.2018 17:56, Matthew Wilcox wrote: > > Why use your own bitmap here? Why not use an IDA which can grow and > > shrink automatically without you needing to play fun games with RCU? > > Bitmap allows to use unlocked set_bit()/clear_bit() to maintain the map > of not empty shrinkers. > > So, the reason to use IDR here is to save bitmap memory? Does this mean > IDA works fast with sparse identifiers? It seems they require per-memcg > lock to call IDR primitives. I just don't have information about this. > > If so, which IDA primitive can be used to set particular id in bitmap? > There is idr_alloc_cyclic(idr, NULL, id, id+1, GFP_KERNEL) only I see > to do that. You're confusing IDR and IDA in your email, which is unfortunate. You can set a bit in an IDA by calling ida_simple_get(ida, n, n, GFP_FOO); You clear it by calling ida_simple_remove(ida, n); The identifiers aren't going to be all that sparse; after all you're allocating them from a global IDA. Up to 62 identifiers will allocate no memory; 63-1024 identifiers will allocate a single 128 byte chunk. Between 1025 and 65536 identifiers, you'll allocate a 576-byte chunk and then 128-byte chunks for each block of 1024 identifiers (*). One of the big wins with the IDA is that it will shrink again after being used. I didn't read all the way through your patchset to see if you bother to shrink your bitmap after it's no longer used, but most resizing bitmaps we have in the kernel don't bother with that part. (*) Actually it's more complex than that... between 1025 and 1086, you'll have a 576 byte chunk, a 128-byte chunk and then use 62 bits of the next pointer before allocating a 128 byte chunk when reaching ID 1087. Similar things happen for the 62 bits after 2048, 3076 and so on. The individual chunks aren't shrunk until they're empty so if you set ID 1025 and then ID 1100, then clear ID 1100, the 128-byte chunk will remain allocated until ID 1025 is cleared. This probably doesn't matter to you.