All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Rapoport <rppt@kernel.org>
To: Hannes Reinecke <hare@suse.com>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>,
	Brian King <brking@us.ibm.com>,
	"James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>,
	Matthew Wilcox <willy@infradead.org>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-scsi@vger.kernel.org, target-devel@vger.kernel.org
Subject: Re: [PATCH 3/4] scsi: ipr: use kmalloc() to allocate IPR dump buffer memory
Date: Wed, 1 Jul 2026 12:52:01 +0300	[thread overview]
Message-ID: <akTjQVQQNdeO9M28@kernel.org> (raw)
In-Reply-To: <7c8f0e70-f49c-4614-af95-002fb2be11ba@suse.com>

On Wed, Jul 01, 2026 at 09:03:06AM +0200, Hannes Reinecke wrote:
> On 6/30/26 12:54 PM, Mike Rapoport (Microsoft) wrote:
> > IPR dump machinery allocates memory to save adapter's crash dump using
> > __get_free_page().
> > 
> > This memory can be allocated with kmalloc() as there's nothing special
> > about it to go directly to the page allocator.
> > 
> > kmalloc() provides a better API that does not require ugly casts and
> > kfree() does not need to know the size of the freed object.
> > 
> > Replace use of __get_free_page() with kmalloc().
> > 
> > Link: https://lore.kernel.org/all/635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com
> > Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
> > ---
> >   drivers/scsi/ipr.c | 4 ++--
> >   1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/scsi/ipr.c b/drivers/scsi/ipr.c
> > index d207e5e81afe..5a212bfdeec2 100644
> > --- a/drivers/scsi/ipr.c
> > +++ b/drivers/scsi/ipr.c
> > @@ -2893,7 +2893,7 @@ static int ipr_sdt_copy(struct ipr_ioa_cfg *ioa_cfg,
> >   	       (ioa_dump->hdr.len + bytes_copied) < max_dump_size) {
> >   		if (ioa_dump->page_offset >= PAGE_SIZE ||
> >   		    ioa_dump->page_offset == 0) {
> > -			page = (__be32 *)__get_free_page(GFP_ATOMIC);
> > +			page = kmalloc(PAGE_SIZE, GFP_ATOMIC);
> >   			if (!page) {
> >   				ipr_trace;
> > @@ -3226,7 +3226,7 @@ static void ipr_release_dump(struct kref *kref)
> >   	spin_unlock_irqrestore(ioa_cfg->host->host_lock, lock_flags);
> >   	for (i = 0; i < dump->ioa_dump.next_page_index; i++)
> > -		free_page((unsigned long) dump->ioa_dump.ioa_data[i]);
> > +		kfree(dump->ioa_dump.ioa_data[i]);
> >   	vfree(dump->ioa_dump.ioa_data);
> >   	kfree(dump);
> > 
>
> I _think_ we can replace this with kvmalloc, and allocate the entire
> dump buffer in one go. Once switched to kmalloc() it's kinda pointless
> to allocate separate page-sized buffers here.

kmalloc() performance is on par with __get_free_page(), but kvmalloc()
would be slower if it falls back to vmalloc(). 

I'm not familiar with the driver to say if this could be an issue here.
 
> Cheers,
> Hannes

-- 
Sincerely yours,
Mike.


  reply	other threads:[~2026-07-01  9:52 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-30 10:54 [PATCH 0/4] scsi: replace __get_free_pages() with kmalloc() Mike Rapoport (Microsoft)
2026-06-30 10:54 ` [PATCH 1/4] scsi: target: file: use kmalloc() to allocate temporary protection buffer Mike Rapoport (Microsoft)
2026-07-01  6:58   ` Hannes Reinecke
2026-06-30 10:54 ` [PATCH 2/4] scsi: proc: use kmalloc() in proc writers Mike Rapoport (Microsoft)
2026-06-30 11:19   ` sashiko-bot
2026-07-01  6:58   ` Hannes Reinecke
2026-07-01 10:52   ` John Garry
2026-07-01 13:50     ` Mike Rapoport
2026-06-30 10:54 ` [PATCH 3/4] scsi: ipr: use kmalloc() to allocate IPR dump buffer memory Mike Rapoport (Microsoft)
2026-06-30 11:28   ` sashiko-bot
2026-07-01  7:03   ` Hannes Reinecke
2026-07-01  9:52     ` Mike Rapoport [this message]
2026-07-01 21:03       ` Brian King
2026-07-02  6:55         ` Mike Rapoport
2026-07-02 19:56           ` Brian King
2026-07-02 22:04             ` Wen Xiong
2026-07-03  7:49           ` Mike Rapoport
2026-07-03  8:35             ` Hannes Reinecke
2026-07-07 13:17             ` Brian King
2026-06-30 10:54 ` [PATCH 4/4] scsi: sym53c8xx_2: replace __get_free_pages() with kmalloc() Mike Rapoport (Microsoft)
2026-06-30 11:37   ` sashiko-bot
2026-07-01  7:04   ` Hannes Reinecke

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=akTjQVQQNdeO9M28@kernel.org \
    --to=rppt@kernel.org \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=brking@us.ibm.com \
    --cc=hare@suse.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=target-devel@vger.kernel.org \
    --cc=willy@infradead.org \
    /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.