From: Paolo Bonzini <pbonzini@redhat.com>
To: Mikulas Patocka <mpatocka@redhat.com>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
Mel Gorman <mgorman@suse.de>, Vlastimil Babka <vbabka@suse.cz>,
David Hildenbrand <david@redhat.com>,
quic_jhugo@quicinc.com, snitzer@kernel.org,
dm <dm-devel@redhat.com>,
linux-mm@kvack.org, linux-arch@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 00/10] Fix confusion around MAX_ORDER
Date: Thu, 28 Sep 2023 18:57:18 +0200 [thread overview]
Message-ID: <b3ed3da7-ffa3-0d35-34c1-27b159af43bb@redhat.com> (raw)
In-Reply-To: <86e7f97a-ac6b-873d-93b2-1121a464989a@redhat.com>
On 9/28/23 09:50, Mikulas Patocka wrote:
>>> 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.
I agree it's somewhat confusing either way but the ship has sailed, the
patch has been included in Linux for several months.
Paolo
WARNING: multiple messages have this Message-ID (diff)
From: Paolo Bonzini <pbonzini@redhat.com>
To: Mikulas Patocka <mpatocka@redhat.com>
Cc: linux-arch@vger.kernel.org, quic_jhugo@quicinc.com,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
David Hildenbrand <david@redhat.com>,
snitzer@kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, dm <dm-devel@redhat.com>,
Mel Gorman <mgorman@suse.de>,
Andrew Morton <akpm@linux-foundation.org>,
Vlastimil Babka <vbabka@suse.cz>
Subject: Re: [dm-devel] [PATCH 00/10] Fix confusion around MAX_ORDER
Date: Thu, 28 Sep 2023 18:57:18 +0200 [thread overview]
Message-ID: <b3ed3da7-ffa3-0d35-34c1-27b159af43bb@redhat.com> (raw)
In-Reply-To: <86e7f97a-ac6b-873d-93b2-1121a464989a@redhat.com>
On 9/28/23 09:50, Mikulas Patocka wrote:
>>> 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.
I agree it's somewhat confusing either way but the ship has sailed, the
patch has been included in Linux for several months.
Paolo
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
next prev parent reply other threads:[~2023-09-28 16:58 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-15 11:31 [PATCH 00/10] Fix confusion around MAX_ORDER Kirill A. Shutemov
2023-03-15 11:31 ` [PATCH 01/10] sparc/mm: Fix MAX_ORDER usage in tsb_grow() Kirill A. Shutemov
2023-03-16 3:04 ` Mike Kravetz
2023-03-17 8:46 ` Mike Rapoport
2023-03-17 8:35 ` Mike Rapoport
2023-03-21 7:48 ` Vlastimil Babka
2023-03-15 11:31 ` [PATCH 02/10] um: Fix MAX_ORDER usage in linux_main() Kirill A. Shutemov
2023-03-17 8:49 ` Mike Rapoport
2023-03-21 7:49 ` Vlastimil Babka
2023-03-15 11:31 ` [PATCH 03/10] floppy: Fix MAX_ORDER usage Kirill A. Shutemov
2023-03-17 8:53 ` Mike Rapoport
2023-03-21 7:53 ` Vlastimil Babka
2023-03-15 11:31 ` [PATCH 04/10] drm/i915: Fix MAX_ORDER usage in i915_gem_object_get_pages_internal() Kirill A. Shutemov
2023-03-15 14:18 ` Tvrtko Ursulin
2023-03-15 15:28 ` Kirill A. Shutemov
2023-03-15 15:35 ` Tvrtko Ursulin
2023-03-15 15:38 ` Kirill A. Shutemov
2023-03-16 8:55 ` Tvrtko Ursulin
2023-03-21 7:57 ` Vlastimil Babka
2023-03-21 7:55 ` Vlastimil Babka
2023-03-15 11:31 ` [PATCH 05/10] genwqe: Fix MAX_ORDER usage Kirill A. Shutemov
2023-03-21 7:59 ` Vlastimil Babka
2023-03-15 11:31 ` [PATCH 06/10] perf/core: Fix MAX_ORDER usage in rb_alloc_aux_page() Kirill A. Shutemov
2023-03-21 8:00 ` Vlastimil Babka
2023-03-15 11:31 ` [PATCH 07/10] mm/page_reporting: Fix MAX_ORDER usage in page_reporting_register() Kirill A. Shutemov
2023-03-21 8:01 ` Vlastimil Babka
2023-03-15 11:31 ` [PATCH 08/10] mm/slub: Fix MAX_ORDER usage in calculate_order() Kirill A. Shutemov
2023-03-16 11:18 ` Vlastimil Babka
2023-03-15 11:31 ` [PATCH 09/10] iommu: Fix MAX_ORDER usage in __iommu_dma_alloc_pages() Kirill A. Shutemov
2023-03-15 12:18 ` Robin Murphy
2023-03-22 12:20 ` Joerg Roedel
2023-03-15 16:07 ` Jacob Pan
2023-03-21 8:05 ` Vlastimil Babka
2023-03-15 11:31 ` [PATCH 10/10] mm, treewide: Redefine MAX_ORDER sanely Kirill A. Shutemov
2023-03-15 15:06 ` kernel test robot
2023-03-15 15:26 ` Kirill A. Shutemov
2023-03-15 15:26 ` kernel test robot
2023-03-15 15:38 ` Kirill A. Shutemov
2023-03-16 17:09 ` Zi Yan
2023-03-16 23:21 ` Kirill A. Shutemov
2023-03-17 13:17 ` Zi Yan
2023-03-16 18:15 ` Mike Kravetz
2023-03-16 23:00 ` Mike Kravetz
2023-03-16 23:30 ` Kirill A. Shutemov
2023-03-17 1:57 ` Vineet Gupta
2023-03-21 11:22 ` Vlastimil Babka
2023-03-22 3:26 ` Michael Ellerman
2023-03-21 16:38 ` [PATCH 00/10] Fix confusion around MAX_ORDER Mel Gorman
2023-03-23 15:03 ` David Laight
2023-09-27 17:11 ` Paolo Bonzini
2023-09-27 17:11 ` [dm-devel] " Paolo Bonzini
2023-09-28 7:50 ` Mikulas Patocka
2023-09-28 7:50 ` [dm-devel] " Mikulas Patocka
2023-09-28 16:57 ` Paolo Bonzini [this message]
2023-09-28 16:57 ` Paolo Bonzini
2023-10-17 10:46 ` Pavel Machek
2023-10-17 10:46 ` Pavel Machek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b3ed3da7-ffa3-0d35-34c1-27b159af43bb@redhat.com \
--to=pbonzini@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=dm-devel@redhat.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mpatocka@redhat.com \
--cc=quic_jhugo@quicinc.com \
--cc=snitzer@kernel.org \
--cc=vbabka@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.