[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <62c2b8cd-ce6a-4e13-a58c-a6b30a0dcf17@grimberg.me>
Date: Tue, 4 Jun 2024 11:24:48 +0300
From: Sagi Grimberg <sagi@...mberg.me>
To: Christoph Hellwig <hch@....de>
Cc: Ofir Gal <ofir.gal@...umez.com>, davem@...emloft.net,
linux-block@...r.kernel.org, linux-nvme@...ts.infradead.org,
netdev@...r.kernel.org, ceph-devel@...r.kernel.org, dhowells@...hat.com,
edumazet@...gle.com, pabeni@...hat.com, kbusch@...nel.org, axboe@...nel.dk,
philipp.reisner@...bit.com, lars.ellenberg@...bit.com,
christoph.boehmwalder@...bit.com, idryomov@...il.com, xiubli@...hat.com
Subject: Re: [PATCH v2 1/4] net: introduce helper sendpages_ok()
On 04/06/2024 7:27, Christoph Hellwig wrote:
> On Tue, Jun 04, 2024 at 12:27:06AM +0300, Sagi Grimberg wrote:
>>>> I still don't understand how a page in the middle of a contiguous range ends
>>>> up coming from the slab while others don't.
>>> I haven't investigate the origin of the IO
>>> yet. I suspect the first 2 pages are the superblocks of the raid
>>> (mdp_superblock_1 and bitmap_super_s) and the rest of the IO is the bitmap.
>> Well, if these indeed are different origins and just *happen* to be a
>> mixture
>> of slab originated pages and non-slab pages combined together in a single
>> bio of a bvec entry,
>> I'd suspect that it would be more beneficial to split the bvec (essentially
>> not allow bio_add_page
>> to append the page to tail bvec depending on a queue limit (similar to how
>> we handle sg gaps).
> So you want to add a PageSlab check to bvec_try_merge_page? That sounds
> fairly expensive..
>
The check needs to happen somewhere apparently, and given that it will
be gated by a queue flag
only request queues that actually needed will suffer, but they will
suffer anyways...
Powered by blists - more mailing lists