Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <CAPM=9twM75GDM9t+9-CSCPDZG3QdcEpQ-X+FzQ4CLUCM7cKLkw@mail.gmail.com>
 <YtHXe4PcWXfihF9Q@dev-arch.thelio-3990X> <CAHk-=wh5DB+OL2QvWPqRhpLLCqW7u_bLucFJpm4v6rZT3T5+zQ@mail.gmail.com>
In-Reply-To: <CAHk-=wh5DB+OL2QvWPqRhpLLCqW7u_bLucFJpm4v6rZT3T5+zQ@mail.gmail.com>
From:   Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sat, 16 Jul 2022 15:08:39 -0700
Message-ID: <CAHk-=wgcECb3cwnB=7Zgf8CBfEYaTWcSzAjfQpTM75_Q5aO7dA@mail.gmail.com>
Subject: Re: [git pull] drm fixes for 5.19-rc7
To:     Nathan Chancellor <nathan@kernel.org>,
        Matthew Auld <matthew.auld@intel.com>,
        Nirmoy Das <nirmoy.das@intel.com>,
        Rodrigo Vivi <rodrigo.vivi@intel.com>,
        =?UTF-8?Q?Thomas_Hellstr=C3=B6m?= 
        <thomas.hellstrom@linux.intel.com>
Cc:     Dave Airlie <airlied@gmail.com>,
        Daniel Vetter <daniel.vetter@ffwll.ch>,
        dri-devel <dri-devel@lists.freedesktop.org>,
        LKML <linux-kernel@vger.kernel.org>
Content-Type: multipart/mixed; boundary="00000000000080390c05e3f36106"
Precedence: bulk

--00000000000080390c05e3f36106
Content-Type: text/plain; charset="UTF-8"

On Sat, Jul 16, 2022 at 2:35 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> That said, even those type simplifications do not fix the fundamental
> issue. That "DIV_ROUND_UP()" still ends up being a 64-bit divide,
> although now it's at least a "64-by-32" bit divide.

Hmm. The "DIV_ROUND_UP()" issue could be solved by just making the
rule be that the max_segment size is always a power of two.

Then you don't need the (expensive!) DIV_ROUND_UP(), and can just use
the regular "round_up()" that works on powers-of-two.

And the simplest way to do that is to just make "max_segments" be 2GB.

The whole "round_down(UINT_MAX, page_alignment)" seems entirely
pointless. Do you really want segments that are some odd number just
under the 4GB mark, and force expensive divides?

For consistency, I used the same value in
i915_rsgt_from_buddy_resource(). I have no idea if that makes sense.

Anyway, the attached patch is COMPLETELY UNTESTED. But it at least
seems to compile. Maybe.

                  Linus

--00000000000080390c05e3f36106
Content-Type: text/x-patch; charset="US-ASCII"; name="patch.diff"
Content-Disposition: attachment; filename="patch.diff"
Content-Transfer-Encoding: base64
Content-ID: <f_l5ofxmky0>
X-Attachment-Id: f_l5ofxmky0

IGRyaXZlcnMvZ3B1L2RybS9pOTE1L2k5MTVfc2NhdHRlcmxpc3QuYyB8IDggKysrKystLS0KIDEg
ZmlsZSBjaGFuZ2VkLCA1IGluc2VydGlvbnMoKyksIDMgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0
IGEvZHJpdmVycy9ncHUvZHJtL2k5MTUvaTkxNV9zY2F0dGVybGlzdC5jIGIvZHJpdmVycy9ncHUv
ZHJtL2k5MTUvaTkxNV9zY2F0dGVybGlzdC5jCmluZGV4IGY2M2I1MGI3MWUxMC4uODMwZGNkODMz
ZDRlIDEwMDY0NAotLS0gYS9kcml2ZXJzL2dwdS9kcm0vaTkxNS9pOTE1X3NjYXR0ZXJsaXN0LmMK
KysrIGIvZHJpdmVycy9ncHUvZHJtL2k5MTUvaTkxNV9zY2F0dGVybGlzdC5jCkBAIC04MSw3ICs4
MSw5IEBAIHN0cnVjdCBpOTE1X3JlZmN0X3NndCAqaTkxNV9yc2d0X2Zyb21fbW1fbm9kZShjb25z
dCBzdHJ1Y3QgZHJtX21tX25vZGUgKm5vZGUsCiAJCQkJCSAgICAgIHU2NCByZWdpb25fc3RhcnQs
CiAJCQkJCSAgICAgIHU2NCBwYWdlX2FsaWdubWVudCkKIHsKLQljb25zdCB1NjQgbWF4X3NlZ21l
bnQgPSByb3VuZF9kb3duKFVJTlRfTUFYLCBwYWdlX2FsaWdubWVudCk7CisJLy8gTWFrZSBzdXJl
IG1heF9zZWdtZW50IChhbmQgdGh1cyBzZWdtZW50X3BhZ2VzKSBpcworCS8vIGEgcG93ZXIgb2Yg
dHdvIHRoYXQgZml0cyBpbiAzMiBiaXRzLgorCWNvbnN0IHU2NCBtYXhfc2VnbWVudCA9IDF1bCA8
PCAzMTsKIAl1NjQgc2VnbWVudF9wYWdlcyA9IG1heF9zZWdtZW50ID4+IFBBR0VfU0hJRlQ7CiAJ
dTY0IGJsb2NrX3NpemUsIG9mZnNldCwgcHJldl9lbmQ7CiAJc3RydWN0IGk5MTVfcmVmY3Rfc2d0
ICpyc2d0OwpAQCAtOTYsNyArOTgsNyBAQCBzdHJ1Y3QgaTkxNV9yZWZjdF9zZ3QgKmk5MTVfcnNn
dF9mcm9tX21tX25vZGUoY29uc3Qgc3RydWN0IGRybV9tbV9ub2RlICpub2RlLAogCiAJaTkxNV9y
ZWZjdF9zZ3RfaW5pdChyc2d0LCBub2RlLT5zaXplIDw8IFBBR0VfU0hJRlQpOwogCXN0ID0gJnJz
Z3QtPnRhYmxlOwotCWlmIChzZ19hbGxvY190YWJsZShzdCwgRElWX1JPVU5EX1VQKG5vZGUtPnNp
emUsIHNlZ21lbnRfcGFnZXMpLAorCWlmIChzZ19hbGxvY190YWJsZShzdCwgcm91bmRfdXAobm9k
ZS0+c2l6ZSwgc2VnbWVudF9wYWdlcyksCiAJCQkgICBHRlBfS0VSTkVMKSkgewogCQlpOTE1X3Jl
ZmN0X3NndF9wdXQocnNndCk7CiAJCXJldHVybiBFUlJfUFRSKC1FTk9NRU0pOwpAQCAtMTU5LDcg
KzE2MSw3IEBAIHN0cnVjdCBpOTE1X3JlZmN0X3NndCAqaTkxNV9yc2d0X2Zyb21fYnVkZHlfcmVz
b3VyY2Uoc3RydWN0IHR0bV9yZXNvdXJjZSAqcmVzLAogewogCXN0cnVjdCBpOTE1X3R0bV9idWRk
eV9yZXNvdXJjZSAqYm1hbl9yZXMgPSB0b190dG1fYnVkZHlfcmVzb3VyY2UocmVzKTsKIAljb25z
dCB1NjQgc2l6ZSA9IHJlcy0+bnVtX3BhZ2VzIDw8IFBBR0VfU0hJRlQ7Ci0JY29uc3QgdTY0IG1h
eF9zZWdtZW50ID0gcm91bmRfZG93bihVSU5UX01BWCwgcGFnZV9hbGlnbm1lbnQpOworCWNvbnN0
IHU2NCBtYXhfc2VnbWVudCA9IDF1IDw8IDMxOwogCXN0cnVjdCBkcm1fYnVkZHkgKm1tID0gYm1h
bl9yZXMtPm1tOwogCXN0cnVjdCBsaXN0X2hlYWQgKmJsb2NrcyA9ICZibWFuX3Jlcy0+YmxvY2tz
OwogCXN0cnVjdCBkcm1fYnVkZHlfYmxvY2sgKmJsb2NrOwo=
--00000000000080390c05e3f36106--