public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Jeff Brasen" <jbrasen@nvidia.com>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: "devel@edk2.groups.io" <devel@edk2.groups.io>,
	"hao.a.wu@intel.com" <hao.a.wu@intel.com>,
	"ray.ni@intel.com" <ray.ni@intel.com>,
	"quic_llindhol@quicinc.com" <quic_llindhol@quicinc.com>,
	"ardb+tianocore@kernel.org" <ardb+tianocore@kernel.org>
Subject: Re: [PATCH v2] MdeModulePkg/NonDiscoverablePciDeviceDxe: Allow partial FreeBuffer
Date: Fri, 5 Aug 2022 16:56:19 +0000	[thread overview]
Message-ID: <DS7PR12MB5789250362A4127303763791CB9E9@DS7PR12MB5789.namprd12.prod.outlook.com> (raw)
In-Reply-To: <CAMj1kXEJmhAK+O6W0QgDdk6X9gXAkuah9+9XOxibLLKvKw9Tsg@mail.gmail.com>



> -----Original Message-----
> From: Ard Biesheuvel <ardb@kernel.org>
> Sent: Tuesday, August 2, 2022 10:51 AM
> To: Jeff Brasen <jbrasen@nvidia.com>
> Cc: devel@edk2.groups.io; hao.a.wu@intel.com; ray.ni@intel.com;
> quic_llindhol@quicinc.com; ardb+tianocore@kernel.org
> Subject: Re: [PATCH v2] MdeModulePkg/NonDiscoverablePciDeviceDxe:
> Allow partial FreeBuffer
> 
> External email: Use caution opening links or attachments
> 
> 
> On Tue, 2 Aug 2022 at 17:32, Jeff Brasen <jbrasen@nvidia.com> wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: Ard Biesheuvel <ardb@kernel.org>
> > > Sent: Friday, July 29, 2022 9:48 AM
> > > To: Jeff Brasen <jbrasen@nvidia.com>
> > > Cc: devel@edk2.groups.io; hao.a.wu@intel.com; ray.ni@intel.com;
> > > quic_llindhol@quicinc.com; ardb+tianocore@kernel.org
> > > Subject: Re: [PATCH v2] MdeModulePkg/NonDiscoverablePciDeviceDxe:
> > > Allow partial FreeBuffer
> > >
> > > External email: Use caution opening links or attachments
> > >
> > >
> > > On Thu, 28 Jul 2022 at 13:25, Jeff Brasen <jbrasen@nvidia.com> wrote:
> > > >
> > > >
> > > > Adding Leif/Ard to CC incase they have any comments on this patch.
> > > >
> > >
> > > This generally looks ok to me. I just wonder if it wouldn't be
> > > simpler to reuse the existing allocation descriptor if it is not
> > > being freed entirely. Given the [presumably] the most common case is
> > > to allocate and then free some pages at the end, lowering the page
> > > count on the existing descriptor would cover most cases, and we'd
> > > only need to allocate new ones if pages are being freed at the start or in
> the middle.
> >
> > There is often freeing at the beginning as well as this is being used to create
> a 64K aligned section of memory in the case. So it over allocates and the
> free's some at the beginning and the end. I could probably make it detect
> and use that but figured this code would support all cases and required less
> case specific detection.
> >
> 
> Ah interesting. Would it help if the allocate routine aligned allocations to their
> size?

The PciIo->AllocateBuffer function doesn't support passing the request in so we would need to know that info beforehand. The current calling in the XHCI driver does a free at the beginning and then the end of the buffer so we could the existing allocation tracker but figured it would be better to correct the function just in case someone called it to free in the middle.

  reply	other threads:[~2022-08-05 16:56 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-14 18:45 [PATCH v2] MdeModulePkg/NonDiscoverablePciDeviceDxe: Allow partial FreeBuffer Jeff Brasen
2022-02-16  6:52 ` [edk2-devel] " Ni, Ray
2022-03-03  4:35   ` Jeff Brasen
2022-05-18  2:59     ` Jeff Brasen
2022-06-17 15:39 ` Jeff Brasen
2022-07-28 20:25   ` Jeff Brasen
2022-07-29 15:47     ` Ard Biesheuvel
2022-08-02 15:32       ` Jeff Brasen
2022-08-02 16:51         ` Ard Biesheuvel
2022-08-05 16:56           ` Jeff Brasen [this message]
2022-08-15 14:42             ` [edk2-devel] " Ard Biesheuvel
2022-09-08 15:39               ` Jeff Brasen
2022-09-08 15:54                 ` Ard Biesheuvel
2022-09-21 16:27                   ` Jeff Brasen
2022-09-21 16:31                     ` Ard Biesheuvel
2022-09-29 16:20                       ` Jeff Brasen
2022-09-30  1:32                         ` 回复: " gaoliming

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-list 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=DS7PR12MB5789250362A4127303763791CB9E9@DS7PR12MB5789.namprd12.prod.outlook.com \
    --to=devel@edk2.groups.io \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox