On 2025/3/12 20:05, Yunsheng Lin wrote:
On 2025/3/12 9:45, Gao Xiang wrote:
On 2025/3/12 06:55, NeilBrown wrote:
On Mon, 10 Mar 2025, Gao Xiang wrote:
- Your new api covers narrow cases compared to the existing
api, although all in-tree callers may be converted
properly,
On Mon, 10 Mar 2025, Gao Xiang wrote:
>
> - Your new api covers narrow cases compared to the existing
> api, although all in-tree callers may be converted
> properly, but it increases mental burden of all users.
> And maybe complicate future potential users again which
> really h
On Mon, 10 Mar 2025, Yunsheng Lin wrote:
> On 3/8/2025 5:02 AM, NeilBrown wrote:
>
> ...
>
> >>
> >>>allocated pages in the array - just like the current
> >>>alloc_pages_bulk().
> >>
> >> I guess 'the total number of allocated pages in the array ' include
> >> the pages which are already
On 2025/3/10 8:32, Gao Xiang wrote:
...
>>
>> Also, it seems the fstests doesn't support erofs yet?
>
> erofs is an read-only filesystem, and almost all xfstests
> cases is unsuitable for erofs since erofs needs to preset
> dataset in advance for runtime testing and only
> read-related interface
On 2025/3/10 20:31, Yunsheng Lin wrote:
On 2025/3/10 8:32, Gao Xiang wrote:
...
Also, it seems the fstests doesn't support erofs yet?
erofs is an read-only filesystem, and almost all xfstests
cases is unsuitable for erofs since erofs needs to preset
dataset in advance for runtime testing
On 2025/3/9 21:40, Yunsheng Lin wrote:
On 3/8/2025 2:43 PM, Dave Chinner wrote:
...
I tested XFS using the below cmd and testcase, testing seems
to be working fine, or am I missing something obvious here
as I am not realy familiar with fs subsystem yet:
That's hardly what I'd call a test.
On 3/8/2025 2:43 PM, Dave Chinner wrote:
...
I tested XFS using the below cmd and testcase, testing seems
to be working fine, or am I missing something obvious here
as I am not realy familiar with fs subsystem yet:
That's hardly what I'd call a test. It barely touches the filesystem
at all, a
On 3/8/2025 5:02 AM, NeilBrown wrote:
...
allocated pages in the array - just like the current
alloc_pages_bulk().
I guess 'the total number of allocated pages in the array ' include
the pages which are already in the array before calling the above
API?
Yes - just what the current f
On Tue, Mar 04, 2025 at 08:09:35PM +0800, Yunsheng Lin wrote:
> On 2025/3/4 16:18, Dave Chinner wrote:
>
> ...
>
> >
> >>
> >> 1.
> >> https://lore.kernel.org/all/bd8c2f5c-464d-44ab-b607-390a87ea4...@huawei.com/
> >> 2.
> >> https://lore.kernel.org/all/20250212092552.1779679-1-linyunsh...@huaw
On Fri, 07 Mar 2025, Yunsheng Lin wrote:
> On 2025/3/7 5:14, NeilBrown wrote:
> > On Thu, 06 Mar 2025, Yunsheng Lin wrote:
> >> On 2025/3/6 7:41, NeilBrown wrote:
> >>> On Wed, 05 Mar 2025, Yunsheng Lin wrote:
>
> For the existing btrfs and sunrpc case, I am agreed that there
> might
On 2025/3/7 5:14, NeilBrown wrote:
> On Thu, 06 Mar 2025, Yunsheng Lin wrote:
>> On 2025/3/6 7:41, NeilBrown wrote:
>>> On Wed, 05 Mar 2025, Yunsheng Lin wrote:
For the existing btrfs and sunrpc case, I am agreed that there
might be valid use cases too, we just need to discuss how to
On Thu, 06 Mar 2025, Yunsheng Lin wrote:
> On 2025/3/6 7:41, NeilBrown wrote:
> > On Wed, 05 Mar 2025, Yunsheng Lin wrote:
> >>
> >> For the existing btrfs and sunrpc case, I am agreed that there
> >> might be valid use cases too, we just need to discuss how to
> >> meet the requirements of differe
On 2025/3/6 7:41, NeilBrown wrote:
> On Wed, 05 Mar 2025, Yunsheng Lin wrote:
>>
>> For the existing btrfs and sunrpc case, I am agreed that there
>> might be valid use cases too, we just need to discuss how to
>> meet the requirements of different use cases using simpler, more
>> unified and effec
On Wed, 05 Mar 2025, Yunsheng Lin wrote:
>
> For the existing btrfs and sunrpc case, I am agreed that there
> might be valid use cases too, we just need to discuss how to
> meet the requirements of different use cases using simpler, more
> unified and effective APIs.
We don't need "more unified".
On 2025/3/4 17:17, Qu Wenruo wrote:
>
>
> 在 2025/2/28 20:14, Yunsheng Lin 写道:
>> As mentioned in [1], it seems odd to check NULL elements in
>> the middle of page bulk allocating, and it seems caller can
>> do a better job of bulk allocating pages into a whole array
>> sequentially without checki
On 2025/3/4 16:18, Dave Chinner wrote:
...
>
>>
>> 1.
>> https://lore.kernel.org/all/bd8c2f5c-464d-44ab-b607-390a87ea4...@huawei.com/
>> 2.
>> https://lore.kernel.org/all/20250212092552.1779679-1-linyunsh...@huawei.com/
>> CC: Jesper Dangaard Brouer
>> CC: Luiz Capitulino
>> CC: Mel Gorman
On 2025/3/4 6:13, Chuck Lever wrote:
> On 2/28/25 4:44 AM, Yunsheng Lin wrote:
>> As mentioned in [1], it seems odd to check NULL elements in
>> the middle of page bulk allocating, and it seems caller can
>> do a better job of bulk allocating pages into a whole array
>> sequentially without checkin
在 2025/2/28 20:14, Yunsheng Lin 写道:
As mentioned in [1], it seems odd to check NULL elements in
the middle of page bulk allocating, and it seems caller can
do a better job of bulk allocating pages into a whole array
sequentially without checking NULL elements first before
doing the page bulk a
On Fri, Feb 28, 2025 at 05:44:20PM +0800, Yunsheng Lin wrote:
> As mentioned in [1], it seems odd to check NULL elements in
> the middle of page bulk allocating, and it seems caller can
> do a better job of bulk allocating pages into a whole array
> sequentially without checking NULL elements first
On 2/28/25 4:44 AM, Yunsheng Lin wrote:
> As mentioned in [1], it seems odd to check NULL elements in
> the middle of page bulk allocating, and it seems caller can
> do a better job of bulk allocating pages into a whole array
> sequentially without checking NULL elements first before
> doing the pa
As mentioned in [1], it seems odd to check NULL elements in
the middle of page bulk allocating, and it seems caller can
do a better job of bulk allocating pages into a whole array
sequentially without checking NULL elements first before
doing the page bulk allocation for most of existing users.
Th
21 matches
Mail list logo
