Re: [PATCH v1 2/6] fs: use on-stack-bio if backing device has BDI_CAP_SYNC capability

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 08/14/2017 02:50 AM, Minchan Kim wrote:
> Hi Jens,
> 
> On Fri, Aug 11, 2017 at 08:26:59AM -0600, Jens Axboe wrote:
>> On 08/11/2017 04:46 AM, Christoph Hellwig wrote:
>>> On Wed, Aug 09, 2017 at 08:06:24PM -0700, Dan Williams wrote:
>>>> I like it, but do you think we should switch to sbvec[<constant>] to
>>>> preclude pathological cases where nr_pages is large?
>>>
>>> Yes, please.
>>>
>>> Then I'd like to see that the on-stack bio even matters for
>>> mpage_readpage / mpage_writepage.  Compared to all the buffer head
>>> overhead the bio allocation should not actually matter in practice.
>>
>> I'm skeptical for that path, too. I also wonder how far we could go
>> with just doing a per-cpu bio recycling facility, to reduce the cost
>> of having to allocate a bio. The on-stack bio parts are fine for
>> simple use case, where simple means that the patch just special
>> cases the allocation, and doesn't have to change much else.
>>
>> I had a patch for bio recycling and batched freeing a year or two
>> ago, I'll see if I can find and resurrect it.
> 
> So, you want to go with per-cpu bio recycling approach to
> remove rw_page?
> 
> So, do you want me to hold this patchset?

I don't want to hold this series up, but I do think the recycling is
a cleaner approach since we don't need to special case anything. I
hope I'll get some time to dust it off, retest, and post soon.

-- 
Jens Axboe

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]
  Powered by Linux