Received-SPF: pass (google.com: domain of linux-kernel+bounces-198709-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
From: =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= <ilpo.jarvinen@linux.intel.com>
Date: Mon, 3 Jun 2024 10:24:39 +0300 (EEST)
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
cc: Chia-I Wu <olvaffe@gmail.com>, amd-gfx@lists.freedesktop.org, 
    dri-devel@lists.freedesktop.org, christian.koenig@amd.com, 
    alexander.deucher@amd.com, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, 
    Alison Schofield <alison.schofield@intel.com>, 
    Dave Jiang <dave.jiang@intel.com>, Baoquan He <bhe@redhat.com>, 
    LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] kernel/resource: optimize find_next_iomem_res
In-Reply-To: <Zlw1_n20oqchAYxH@smile.fi.intel.com>
Message-ID: <783e9d9a-e408-c6f0-9a4b-050e1979b919@linux.intel.com>
References: <20240531053704.2009827-1-olvaffe@gmail.com> <ZlmQ3_wcL3cgp4Hb@smile.fi.intel.com> <CAPaKu7SsD+X7KAO=3vEYU_7YGM_f+7k1fdC9nEK=-NaJw8oYaA@mail.gmail.com> <Zlw1_n20oqchAYxH@smile.fi.intel.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="8323328-947370823-1717399436=:1529"
Content-ID: <ac58b535-760b-99ee-4936-892d3e4f1ed9@linux.intel.com>

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323328-947370823-1717399436=:1529
Content-Type: text/plain; CHARSET=UTF-8
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-ID: <9a23e7b3-9da0-cdcd-f514-8f55036748af@linux.intel.com>

On Sun, 2 Jun 2024, Andy Shevchenko wrote:

> On Fri, May 31, 2024 at 02:31:45PM -0700, Chia-I Wu wrote:
> > On Fri, May 31, 2024 at 1:57=E2=80=AFAM Andy Shevchenko <
> > andriy.shevchenko@linux.intel.com> wrote:
> > > On Thu, May 30, 2024 at 10:36:57PM -0700, Chia-I Wu wrote:
>=20
> ...
>=20
> > > P.S> I'm not so sure about this change. It needs a thoroughly testing=
, esp.
> > > in PCI case. Cc'ing to Ilpo.
>=20
> > What's special about PCI?
>=20
> PCI, due to its nature, may rebuild resources either by shrinking or expa=
nding
> of the entire subtree after the PCI bridge in question. And this may happ=
en at
> run-time due to hotplug support. But I'm not a deep expert in this area, =
Ilpo
> knows much more than me.

There is code which clearly tries to do expanding resource but that=20
usually fails to work as intended because of a parent resource whose size=
=20
is fixed because it's already assigned.

Some other code might block shrinking too under certain conditions.

This area would need to be reworked in PCI core but it's massive and=20
scary looking change.

--=20
 i.
--8323328-947370823-1717399436=:1529--