netdev - Re: [PATCH for-next] mlx4_core: Roll back round robin bitmap allocation commit for CQs, SRQs, and MPTs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <20131209.211233.415056494606198185.davem@davemloft.net>
Date:	Mon, 09 Dec 2013 21:12:33 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	ogerlitz@...lanox.com
Cc:	roland@...nel.org, linux-rdma@...r.kernel.org,
	netdev@...r.kernel.org, vlad@...lanox.com, jackm@....mellanox.co.il
Subject: Re: [PATCH for-next] mlx4_core: Roll back round robin bitmap
 allocation commit for CQs, SRQs, and MPTs

From: Or Gerlitz <ogerlitz@...lanox.com>
Date: Sun,  8 Dec 2013 16:50:17 +0200

> From: Jack Morgenstein <jackm@....mellanox.co.il>
> 
> Commit f4ec9e9 "mlx4_core: Change bitmap allocator to work in round-robin fashion" 
> introduced round-robin allocation (via bitmap) for all resources which allocate 
> via a bitmap.
> 
> Round robin allocation is desirable for mcgs, counters, pd's, UARs, and xrcds.
> These are simply numbers, with no involvement of ICM memory mapping.
> 
> Round robin is required for QPs, since we had a problem with immediate
> reuse of a 24-bit QP number (commit f4ec9e9).
> 
> However, for other resources which use the bitmap allocator and involve
> mapping ICM memory -- MPTs, CQs, SRQs -- round-robin is not desirable.
> 
> What happens in these cases is the following:
> 
> ICM memory is allocated and mapped in chunks of 256K.
> 
> Since the resource allocation index goes up monotonically, the allocator
> will eventually require mapping a new chunk. Now, chunks are also unmapped
> when their reference count goes back to zero.  Thus, if a single app is
> running and starts/exits frequently we will have the following situation:
> 
> When the app starts, a new chunk must be allocated and mapped.
> 
> When the app exits, the chunk reference count goes back to zero, and the
> chunk is unmapped and freed. Therefore, the app must pay the cost of allocation
> and mapping of ICM memory each time it runs (although the price is paid only when
> allocating the initial entry in the new chunk).
> 
> For apps which allocate MPTs/SRQs/CQs and which operate as described above,
> this presented a performance problem.
> 
> We therefore roll back the round-robin allocator modification for MPTs, CQs, SRQs.
> 
> Reported-by: Matthew Finlay <matt@...lanox.com>
> Signed-off-by: Jack Morgenstein <jackm@....mellanox.co.il>
> Signed-off-by: Or Gerlitz <ogerlitz@...lanox.com>

Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html