From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 82635CE7B08 for ; Thu, 28 Sep 2023 07:50:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E38288D008E; Thu, 28 Sep 2023 03:50:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DE70B8D0002; Thu, 28 Sep 2023 03:50:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CD4F58D008E; Thu, 28 Sep 2023 03:50:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id C0B528D0002 for ; Thu, 28 Sep 2023 03:50:16 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 92E3D40A51 for ; Thu, 28 Sep 2023 07:50:16 +0000 (UTC) X-FDA: 81285233232.16.3F8106C Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf13.hostedemail.com (Postfix) with ESMTP id 23B0A20028 for ; Thu, 28 Sep 2023 07:50:13 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=KbZ+TWVw; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf13.hostedemail.com: domain of mpatocka@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=mpatocka@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1695887414; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=NDF7CH8bTKhRjSz3An4kXrtZKcHrytXsVm7QLB4Bnu4=; b=x1OBb56trRjwuUO3LG6oGcc4RsLL4X5yFTcbAL9Z1epMMuSNVmWVDhYZ5gNvrrUIA91J00 xFpb9fXtrvaFZ8PXfVOs6JAuHB/S/GN50YLg+ZFH7JC6Rgji4Uf8oBTljB/HBu6R8+/rJ1 Ps3u1nij2iZOslxYiv/eBtkXJSGLnYE= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=KbZ+TWVw; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf13.hostedemail.com: domain of mpatocka@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=mpatocka@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695887414; a=rsa-sha256; cv=none; b=m5bQZDYC8Zy7n0hpppkPIU+xKl8LnYbe3ughwUfGy37bF5P+Ijx8yH+6ueIOign98+td3/ fsPY+Twg9m7/MtAquovWXrJuamOvHusn1KTyGz/RkjdWAIgasauZhyj8lqJNwVKFMYFW0i oQqoJXRRMY5ZbqbsjVIh5Q3J8CMswoY= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1695887412; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=NDF7CH8bTKhRjSz3An4kXrtZKcHrytXsVm7QLB4Bnu4=; b=KbZ+TWVwx8q2nm935U0EbJZiMFc/ez1zcqIVs2eT9PtUgKq24aw/adjHcTrXI4WNdj0dAf dHIlJwscjO/wcCBB5LxwMLZhPPk6KxwAPDMsvDmtHkH2q7aZgrb/bqhB5B19FttauZPaBu 920xQ2mNLyyx7dfOeR1aa6V4Is0cLag= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-307-GL0GjoedOkilqIBhd60-qQ-1; Thu, 28 Sep 2023 03:50:08 -0400 X-MC-Unique: GL0GjoedOkilqIBhd60-qQ-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 1E3953C40C06; Thu, 28 Sep 2023 07:50:08 +0000 (UTC) Received: from file1-rdu.file-001.prod.rdu2.dc.redhat.com (unknown [10.11.5.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B67B32156702; Thu, 28 Sep 2023 07:50:07 +0000 (UTC) Received: by file1-rdu.file-001.prod.rdu2.dc.redhat.com (Postfix, from userid 12668) id A104730C1C0A; Thu, 28 Sep 2023 07:50:07 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by file1-rdu.file-001.prod.rdu2.dc.redhat.com (Postfix) with ESMTP id 981B63FD4B; Thu, 28 Sep 2023 09:50:07 +0200 (CEST) Date: Thu, 28 Sep 2023 09:50:07 +0200 (CEST) From: Mikulas Patocka To: Paolo Bonzini cc: "Kirill A. Shutemov" , Andrew Morton , Mel Gorman , Vlastimil Babka , David Hildenbrand , quic_jhugo@quicinc.com, snitzer@kernel.org, dm , linux-mm@kvack.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 00/10] Fix confusion around MAX_ORDER In-Reply-To: <3c25ec6f-cd33-9445-a76f-6ec2c30755f5@redhat.com> Message-ID: <86e7f97a-ac6b-873d-93b2-1121a464989a@redhat.com> References: <20230315113133.11326-1-kirill.shutemov@linux.intel.com> <3c25ec6f-cd33-9445-a76f-6ec2c30755f5@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Scanned-By: MIMEDefang 3.1 on 10.11.54.6 X-Rspamd-Queue-Id: 23B0A20028 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: nhzfuoza7pt1rshk84cs6u91sj3yw4yf X-HE-Tag: 1695887412-359662 X-HE-Meta: U2FsdGVkX19NvKSikspSH0hrcTnIdmG0ZdVi4uQ3OQpqMvOOAKeUnpKoeSXC7Pn2SZka1cOwejihCVIpb+W8Ddy46RRCWCMR+15322bn64B7WyhJmIc9CSVcGT5LrStmgw7SSZ4RgiaB4nfcKclF5b34TvgOWnV4ZbsEduIvNUReS/Bn7xyNQhrmAWyUyL4q537fOm13hhv4mTzgSwkNkoR7ZYMaWcNUQBYCWyZsaDko5LeYvL6OC4wec6IVGGOxstUTnUfifHW72TgNfcfpc4b0byEqaon0BHmilxy6UCTKqUpCt+dn8CMhNAy7w8560bTH3854zcomfKwhwBmmUyYSRzc4GrHpsm4OX4ym3CJneMGpf66daGACE0ZxIHSgO8A2XrWTsjN7YVI7FUU6wEBp/Pw5Cit4ncJFfS9jpjRhfjtUmUOPNd6ov8TcbmCLQ5Uft/sAykZLj7zxtT9hqRZWP/mRorMehKXvtUTVR0DA5a2dbinGATIH135Me8K+4KfkCFrJbD0tDQ4snicydGmyvaN6IEf+TBXjGMTOGkV5isZ6BtpQ7Z/jUr5yJzTBzr3T8l9DPGG24NXyF+tC8e7X0YJA3O72eH7fnmzXtcimR/DXeDy0uXt+tceiNwWhl1eqWtd6FaP9kwAoat1j921yT9TRaZxNOeKzOnH9q7FS7rFGql6f6JgURi4G8VQlcQQGP8strF+UsKfbmHKPbLwd36ROAWfbYgT3iGbsmuB0CXBra4cdKefw7D3f/x4vnF3ogqNsIc4xJ1X5qnUuHZ1nb4362bXyuBlK1MsSNKgp0sRYFUSxPBkXyI2NIDJEsMAPCX6O1IN1Ft1SVZEdwPOoyzhFUQyxOBL5+FzqAdAN/ZRWb6fqRb5Vl0mF+ZDGO+w+w+fW1+3CRFTkvvKr5dFd48UR85iA/tl90Cdnim/XuzgvX4+KQIXSZg+ZXLoZHJSnXHgoa4ggr7u9Az1 11MmVLqx cWz3yjNdpDV7cqJnKMKk/jhClIhZTZcuRiuhOAvWJPUetCZCYI7WuaOVVb/x7gPZI4IIHFFIqmwVxrdUa9Ni0yM1g1UGBWdmem9ilEw5vK6G/50XwCJVWZcuNyigYDcVex6eMbPcoH5aseoOM8c809F2IbB+6PSJdmFEe0pC3ZCymvsdtFw1ztXK3EKSBBQJxvLyM9QbvllNFs4uTPKfrA2Oipw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, 27 Sep 2023, Paolo Bonzini wrote: > On 3/15/23 12:31, Kirill A. Shutemov wrote: > > MAX_ORDER currently defined as number of orders page allocator supports: > > user can ask buddy allocator for page order between 0 and MAX_ORDER-1. > > > > This definition is counter-intuitive and lead to number of bugs all over > > the kernel. > > > > Fix the bugs and then change the definition of MAX_ORDER to be > > inclusive: the range of orders user can ask from buddy allocator is > > 0..MAX_ORDER now. I think that exclusive MAX_ORDER is more intuitive in the C language - i.e. if you write "for (i = 0; i < MAX_ORDER; i++)", you are supposed to loop over all allowed values. If you declare an array "void *array[MAX_ORDER];" you are supposed to hold a value for each allowed order. Pascal has for loops and array dimensions with inclusive ranges - and it is more prone to off-by-one errors. Mikulas