Messages in this thread | | | Date | Thu, 16 Feb 2023 12:45:11 -0500 (EST) | From | Mikulas Patocka <> | Subject | Re: [dm-devel] [v2 PATCH 0/5] Introduce mempool pages bulk allocator and use it in dm-crypt |
| |
On Wed, 15 Feb 2023, Yang Shi wrote:
> On Wed, Feb 15, 2023 at 4:23 AM Mikulas Patocka <mpatocka@redhat.com> wrote: > > > > > > > > On Tue, 14 Feb 2023, Yang Shi wrote: > > > > > > > > Changelog: > > > RFC -> v2: > > > * Added callback variant for page bulk allocator and mempool bulk allocator > > > per Mel Gorman. > > > * Used the callback version in dm-crypt driver. > > > * Some code cleanup and refactor to reduce duplicate code. > > > > > > rfc: https://lore.kernel.org/linux-mm/20221005180341.1738796-1-shy828301@gmail.com/ > > > > Hi > > > > This seems like unneeded complication to me. We have alloc_pages(), it can > > allocate multiple pages efficiently, so why not use it? > > The alloc_pages() allocates *contiguous* pages, but dm-crypt doesn't > need contiguous pages at all. This may incur unnecessary compaction
It doesn't hurt that the pages are contiguous - and allocating and freeing a few compound pages is even faster than allocating and freeing many 0-order pages.
> overhead to the dm-crypt layer when memory is fragmented.
The compaction overhead may be suppressed by the GFP flags (i.e. don't use __GFP_DIRECT_RECLAIM).
> The bulk allocator is a good fit to this usecase, which allocates > multiple order-0 pages. > > In addition, filesystem writeback doesn't guarantee power-of-2 pages > every time IIUC. But alloc_pages() just can allocate power-of-2 pages.
So, we can allocate more compound pages for the non-power-of-2 case - see the next patch that I'm sending.
> > > > I suggest to modify crypt_alloc_buffer() to use alloc_pages() and if > > alloc_pages() fails (either because the system is low on memory or because > > memory is too fragmented), fall back to the existing code that does > > mempool_alloc(). > > My PoC patches just did this way, but called bulk allocator. There may > be other potential mepool users as I listed in this cover letter, > which may get benefits from bulk allocator. So introducing a new bulk > mempool API seems better for long run although we just have one user > for now. And it makes other uses easier to gain the benefit by just > calling the new API.
This mempool bulk refactoring just makes the code bigger. And it is not needed - dm-crypt can fall-back to non-bulk mempool allocations.
In the next email, I'm sending a patch that is noticeably smaller and that uses alloc_pages()/__free_pages().
Mikulas
| |