linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Tony Battersby <tonyb@cybernetics.com>
To: Keith Busch <kbusch@meta.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Matthew Wilcox <willy@infradead.org>
Cc: Keith Busch <kbusch@kernel.org>
Subject: Re: [PATCH 11/11] dmapool: link blocks across pages
Date: Mon, 5 Dec 2022 13:07:15 -0500	[thread overview]
Message-ID: <8fc56daf-7f8d-b62b-b6bf-4da4ca87ea20@cybernetics.com> (raw)
In-Reply-To: <20221205145937.54367-12-kbusch@meta.com>

On 12/5/22 09:59, Keith Busch wrote:
> From: Keith Busch <kbusch@kernel.org>
>
> The allocated dmapool pages are never freed for the lifetime of the
> pool. There is no need for the two level list+stack lookup for finding a
> free block since nothing is ever removed from the list. Just use a
> simple stack, reducing time complexity to constant.
>
> The implementation inserts the stack linking elements and the dma handle
> of the block within itself when freed. This means the smallest possible
> dmapool block is increased to at most 16 bytes to accomodate these
> fields, but there are no exisiting users requesting a dma pool smaller
> than that anyway.

Great work!

I notice that the comment at the top of dmapool.c describes the old
design ("Free blocks are tracked in an unsorted singly-linked
list of free blocks within the page."), so you need to delete or update
that part of the comment.

>  struct dma_pool {		/* the pool */
>  	struct list_head page_list;
>  	spinlock_t lock;
>  	struct device *dev;
> +	struct dma_block *next_block;
>  	unsigned int size;
>  	unsigned int allocation;
>  	unsigned int boundary;
> +	unsigned int nr_blocks;
> +	unsigned int nr_active;
> +	unsigned int nr_pages;

I think nr_blocks, nr_active, and nr_pages should be size_t rather than
unsigned int since they count the number of objects in the entire pool,
and it would be theoretically possible to allocate more than 2^32 objects.


> @@ -199,22 +217,24 @@ EXPORT_SYMBOL(dma_pool_create);
>  
>  static void pool_initialise_page(struct dma_pool *pool, struct dma_page *page)
>  {
> -	unsigned int offset = 0;
> -	unsigned int next_boundary = pool->boundary;
> -
> -	page->in_use = 0;
> -	page->offset = 0;
> -	do {
> -		unsigned int next = offset + pool->size;
> -		if (unlikely((next + pool->size) >= next_boundary)) {
> -			next = next_boundary;
> +	unsigned int next_boundary = pool->boundary, offset = 0;
> +	struct dma_block *block;
> +
> +	while (offset < pool->allocation) {
> +		if (offset > next_boundary) {

This is incorrect.  I believe the correct comparison should be:

+    while (offset + pool->size <= pool->allocation) {
+        if (offset + pool->size > next_boundary) {

That should handle all the weird possible combinations of size,
boundary, and allocation.

Tony Battersby
Cybernetics



  reply	other threads:[~2022-12-05 18:07 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-05 14:59 [PATCH 00/11] dmapool enhancements Keith Busch
2022-12-05 14:59 ` [PATCH 01/11] dmapool: add alloc/free performance test Keith Busch
2022-12-06  2:17   ` kernel test robot
2022-12-05 14:59 ` [PATCH 02/11] dmapool: remove checks for dev == NULL Keith Busch
2022-12-05 14:59 ` [PATCH 03/11] dmapool: use sysfs_emit() instead of scnprintf() Keith Busch
2022-12-05 14:59 ` [PATCH 04/11] dmapool: cleanup integer types Keith Busch
2022-12-05 14:59 ` [PATCH 05/11] dmapool: speedup DMAPOOL_DEBUG with init_on_alloc Keith Busch
2022-12-05 14:59 ` [PATCH 06/11] dmapool: move debug code to own functions Keith Busch
2022-12-05 14:59 ` [PATCH 07/11] dmapool: rearrange page alloc failure handling Keith Busch
2022-12-05 14:59 ` [PATCH 08/11] dmapool: consolidate page initialization Keith Busch
2022-12-05 14:59 ` [PATCH 09/11] dmapool: simplify freeing Keith Busch
2022-12-05 14:59 ` [PATCH 10/11] dmapool: don't memset on free twice Keith Busch
2022-12-05 14:59 ` [PATCH 11/11] dmapool: link blocks across pages Keith Busch
2022-12-05 18:07   ` Tony Battersby [this message]
2022-12-05 22:34   ` kernel test robot
2022-12-11 15:24   ` kernel test robot

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=8fc56daf-7f8d-b62b-b6bf-4da4ca87ea20@cybernetics.com \
    --to=tonyb@cybernetics.com \
    --cc=kbusch@kernel.org \
    --cc=kbusch@meta.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox