From: Christoph Hellwig <hch@infradead.org>
To: Brian Johannesmeyer <bjohannesmeyer@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
linux-hardening@vger.kernel.org,
Raphael Isemann <teemperor@gmail.com>,
Cristiano Giuffrida <giuffrida@cs.vu.nl>,
Herbert Bos <h.j.bos@vu.nl>, Greg KH <gregkh@linuxfoundation.org>,
Keith Busch <kbusch@kernel.org>
Subject: Re: [RFC v2 1/2] dmapool: Move pool metadata into non-DMA memory
Date: Wed, 20 Nov 2024 01:37:17 -0800 [thread overview]
Message-ID: <Zz2tzVqql2RMSFN4@infradead.org> (raw)
In-Reply-To: <20241119205529.3871048-2-bjohannesmeyer@gmail.com>
On Tue, Nov 19, 2024 at 09:55:28PM +0100, Brian Johannesmeyer wrote:
> + page->blocks_per_page = pool->allocation / pool->size;
> + page->blocks = kmalloc_array(page->blocks_per_page,
> + sizeof(struct dma_block), GFP_KERNEL);
Given that you now need an array of the blocks anyway, it might make
sense to switch from a linked list to a bitmap for tracking free state,
which would be a lot more efficient as you only need a bit per block
as tracking overhead instead of a two pointers and a dma_addr_t.
e.g. do a find_first_zero_bit() to find the ffree slot, then calculate
the dma_addr and virt address by simple offseting into the dma_page
ones with bitnr * pool->size.
next prev parent reply other threads:[~2024-11-20 9:37 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-19 20:55 [RFC v2 0/2] dmapool: Mitigate device-controllable mem. corruption Brian Johannesmeyer
2024-11-19 20:55 ` [RFC v2 1/2] dmapool: Move pool metadata into non-DMA memory Brian Johannesmeyer
2024-11-20 9:37 ` Christoph Hellwig [this message]
2024-11-20 23:46 ` Brian Johannesmeyer
2024-11-21 5:03 ` Christoph Hellwig
2024-11-21 17:48 ` Brian Johannesmeyer
2024-11-19 20:55 ` [RFC v2 2/2] dmapool: Use pool_find_block() in pool_block_err() Brian Johannesmeyer
2024-11-19 22:14 ` [RFC v2 0/2] dmapool: Mitigate device-controllable mem. corruption Greg KH
2024-11-19 22:22 ` Brian Johannesmeyer
2024-11-20 9:29 ` Christoph Hellwig
2024-11-20 15:56 ` Keith Busch
2024-11-20 18:51 ` Keith Busch
2024-11-20 21:58 ` Brian Johannesmeyer
2024-11-21 3:37 ` Keith Busch
2024-11-21 17:31 ` Brian Johannesmeyer
2024-11-21 18:06 ` Keith Busch
2024-11-21 19:07 ` Brian Johannesmeyer
2024-11-22 19:19 ` Brian Johannesmeyer
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=Zz2tzVqql2RMSFN4@infradead.org \
--to=hch@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=bjohannesmeyer@gmail.com \
--cc=giuffrida@cs.vu.nl \
--cc=gregkh@linuxfoundation.org \
--cc=h.j.bos@vu.nl \
--cc=kbusch@kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=teemperor@gmail.com \
/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.