[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240604042738.GA28853@lst.de>
Date: Tue, 4 Jun 2024 06:27:38 +0200
From: Christoph Hellwig <hch@....de>
To: Sagi Grimberg <sagi@...mberg.me>
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, hch@....de,
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 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..
Powered by blists - more mailing lists