Re: Unusual value of optimal_io_size prevents bcache initialization

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


> 2023年9月24日 22:06,Coly Li <colyli@xxxxxxx> 写道:


>>> Maybe bcache should not directly use q->limits.io_opt as d->stripe_size,
>>> it should be some value less than 1<<31 and aligned to optimal_io_size.
>>> After the code got merged into kernel for 10+ years, it is time to improve
>>> this calculation :-) >
>> Yeah, one of the other doubts I had was exactly regarding this value and if it is still "actual" to calculate it that way. Unfortunately, I don't have the expertise to have an opinion on it. Would you be so kind to share your knowledge and let me understand why it is calculated this way and why is it using the optimal io size? Is it using it to "writeback" optimal-sized blokes?
> Most of the conditions when underlying hardware doesn’t declare its optimal io size, bcache uses 1<<31 as a default stripe size. It works fine for decade, so I will use it and make sure it is aligned to value of optimal io size. It should work fine. And I will compose a simple patch for this fix.
>>>> Another consideration, stripe_sectors_dirty and full_dirty_stripes, the two
>>>> arrays allocated using n, are being used just in writeback mode, is this
>>>> correct? In my specific case, I'm not planning to use writeback mode so I
>>>> would expect bcache to not even try to create those arrays. Or, at least, to
>>>> not create them during initialization but just in case of a change in the
>>>> working mode (i.e. write-through -> writeback).
>>> Indeed, Mingzhe Zou (if I remember correctly) submitted a patch for this
>>> idea, but it is blocked by other depending patches which are not finished
>>> by me. Yes I like the idea to dynamically allocate/free d->stripe_sectors_dirty
>>> and d->full_dirty_stripes when they are necessary. I hope I may help to make
>>> the change go into upstream sooner.
>>> I will post a patch for your testing.
>> This would be great! Thank you very much! On the other side, if there's anything I can do to help I would be glad to contribute.
> I will post a simple patch for the reported memory allocation failure for you to test soon.

Hi Andrea,

Could you please try the attached patch and see whether it makes some difference? Thank you in advance.

Coly Li

Attachment: 0001-bcache-avoid-oversize-memory-allocation-by-small-str.patch
Description: Binary data

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux ARM Kernel]     [Linux Filesystem Development]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux