Received: by 10.223.185.116 with SMTP id b49csp4721610wrg; Tue, 27 Feb 2018 01:12:36 -0800 (PST) X-Google-Smtp-Source: AH8x224qDSVKVEKhwwhbZkOq1M264neIFF/5GSkMtaBuzryyjLGlB8XhwG4LD/XdzUcOcD2uKf3b X-Received: by 10.99.38.67 with SMTP id m64mr10743326pgm.2.1519722756667; Tue, 27 Feb 2018 01:12:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519722756; cv=none; d=google.com; s=arc-20160816; b=cKacEJcYkkyLDkZuvjeif93rt5EmneFC6vvsD4FbEBdtiuP0AABAaxGZrWhx23v0Z7 jpL9ODcvTGq46xefbhK+jhADEXAAJnk3MBdeuzH+D1P96z8LqfzF0Y+GYL5lVH0JpVSP cgJQsUAVjXdVmiWI4LjEV/I11N5KB+e9XzPcfwx6ZwBTVbPLX0gEnH/hSm/LewvZY1X3 T9AmG0nPdKoszdX+IhazASEZsN4gXbsfvk+69rn1NqTdCvylTaKLhfCMVxikohaKXxGi 7cysxqeNhlRgpj74FF/zE7AKyt8n+wcCI0wsiqBIfUJ8AMUcYiDXJR84irM3luhOyfE4 AIdQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date:dkim-signature:arc-authentication-results; bh=ng9WErz4VWGd17nWB3Mma+kKMqwXTFbYjyp2yCtLvpg=; b=L7omjRm9nVB/C9/q4nMwakKGSD8ESssdl38wCAY8ylk/fiOMxczEzKg5QH2g1rmdaw J17TJSHJAO5KbWtnk11i6uIXvF8Q9sKGKr0PSUwaUe9q1hOeE53pOlPdOlA08Kg2pSAE FaJMUs/BA2TqGbMfJjCnfp3wpqdIlLvQMDAQSteFzLjIFKrjL41Pvw92OPFit47FunLY sBm+fRCk9RliQeowZCUvSLmt9n/hzLW1598jAMIJ/wuRAgwcyAZpjBcrNJJtK2+E2ayb kYtRX5mu/gZkwAFA90kK6Z2e8yionOKIp8xVyYApedRwwK7YMbER9sVOlwewgtQLIld3 flFA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Ld+HKNuz; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m189si8156791pfc.410.2018.02.27.01.12.21; Tue, 27 Feb 2018 01:12:36 -0800 (PST) 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=pass header.i=@gmail.com header.s=20161025 header.b=Ld+HKNuz; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752382AbeB0JLj (ORCPT + 99 others); Tue, 27 Feb 2018 04:11:39 -0500 Received: from mail-pg0-f43.google.com ([74.125.83.43]:42903 "EHLO mail-pg0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752090AbeB0JLg (ORCPT ); Tue, 27 Feb 2018 04:11:36 -0500 Received: by mail-pg0-f43.google.com with SMTP id y8so7283692pgr.9 for ; Tue, 27 Feb 2018 01:11:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :organization:mime-version:content-transfer-encoding; bh=ng9WErz4VWGd17nWB3Mma+kKMqwXTFbYjyp2yCtLvpg=; b=Ld+HKNuzzrPkDeKhGJPB2L3Sm923PgiNLbTwx7FKknTeRohiWshnqQu19vDk4vhx2t 4Q1ITzSLOJ1kGTI6IxM2pYGdTQSeHm41wqJDhiBbmtehdjo6mhPg46CJDZjttCfACrUF lkO7nDmzqMIKC6UX4Gfx4bP5YqVrnaUfWxigm1lnnoE+Y1/62RfR4LHvi1yp0GiQoxec Gvl50j4mLV8aSRDU8VQoXW3AssTDdziG7LublvnccycVmdN96+NPC0eLk1UZC+QW5mSR gXlWxbCh5Jy8FKzgyOCc+i7oLeFIVBkzORbtYCiErJwvFXb+zP/8neF3ys0Y0QALrjN3 xZHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:organization:mime-version:content-transfer-encoding; bh=ng9WErz4VWGd17nWB3Mma+kKMqwXTFbYjyp2yCtLvpg=; b=kPEWVkeue5oc+Txx4E4g5jEV+NieMkHBQsNT6KXVImpgZpEufLuuuHfLS2tYLVhohW 5PtYHJ2vdLHOkZrqMHdB96yvPqxsynDT4sCb1zPvGK2Jpvf8ajlgL/S4PzMxTHVvOWIl nbkI8bTBPeQ4fso4CXhDb+GYegEss/HChBwuU41BragkahulH1oXswjF3earUbFGp/Uw q/5MYUxbQBpbJh7MADFFrIQGvwp+lJiMqIoscp9DWee8lMDkFfwbcU88Rjn2l8T3TsjT VH7mPA2VTSz8n7QeQl0rMdvSBhKWbnKiWpBINvhpnWoGomZrrApVW52hIJ5wNGONN3R2 VDmQ== X-Gm-Message-State: APf1xPBo2+y+avK7nr18kszcq+Du3opHIkc7G57qTPCmemdoSqm4earX uJ3zFdEl4GSTTyNyoVuqfx8= X-Received: by 10.98.8.92 with SMTP id c89mr13316892pfd.154.1519722695861; Tue, 27 Feb 2018 01:11:35 -0800 (PST) Received: from roar.ozlabs.ibm.com (115-64-218-172.tpgi.com.au. [115.64.218.172]) by smtp.gmail.com with ESMTPSA id d64sm20394706pfa.118.2018.02.27.01.11.32 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 27 Feb 2018 01:11:34 -0800 (PST) Date: Tue, 27 Feb 2018 19:11:25 +1000 From: Nicholas Piggin To: "Aneesh Kumar K.V" Cc: Christophe Leroy , linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org Subject: Re: [RFC REBASED 5/5] powerpc/mm/slice: use the dynamic high slice size to limit bitmap operations Message-ID: <20180227191125.659d5cbe@roar.ozlabs.ibm.com> In-Reply-To: <87bmga7qng.fsf@linux.vnet.ibm.com> References: <02a62db83282b5ef3e0e8281fdc46fa91beffc86.1518382747.git.christophe.leroy@c-s.fr> <5badd882663833576c10b8aafe235fe1e443f119.1518382747.git.christophe.leroy@c-s.fr> <87bmga7qng.fsf@linux.vnet.ibm.com> Organization: IBM X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 27 Feb 2018 14:31:07 +0530 "Aneesh Kumar K.V" wrote: > Christophe Leroy writes: > > > The number of high slices a process might use now depends on its > > address space size, and what allocation address it has requested. > > > > This patch uses that limit throughout call chains where possible, > > rather than use the fixed SLICE_NUM_HIGH for bitmap operations. > > This saves some cost for processes that don't use very large address > > spaces. > > I haven't really looked at the final code. One of the issue we had was > with the below scenario. > > mmap(addr, len) where addr < 128TB and addr+len > 128TB We want to make > sure we build the mask such that we don't find the addr available. We should run it through the mmap regression tests. I *think* we moved all of that logic from the slice code to get_ummapped_area before going in to slices. I may have missed something though, it would be good to have more eyes on it. Thanks, Nick