Re: [PATCH v6 4/5] mm/migrate: skip migrating folios under writeback with AS_WRITEBACK_INDETERMINATE mappings

[Jingbo Xu <jefflexu@linux.alibaba.com>]

On 1/8/25 12:15 AM, Miklos Szeredi wrote:
> On Mon, 6 Jan 2025 at 19:17, Shakeel Butt <shakeel.butt@linux.dev> wrote:
>>
>> On Mon, Jan 06, 2025 at 11:19:42AM +0100, Miklos Szeredi wrote:
>>> On Fri, 3 Jan 2025 at 21:31, David Hildenbrand <david@redhat.com> wrote:
>>>> In any case, having movable pages be turned unmovable due to persistent
>>>> writaback is something that must be fixed, not worked around. Likely a
>>>> good topic for LSF/MM.
>>>
>>> Yes, this seems a good cross fs-mm topic.
>>>
>>> So the issue discussed here is that movable pages used for fuse
>>> page-cache cause a problems when memory needs to be compacted. The
>>> problem is either that
>>>
>>>  - the page is skipped, leaving the physical memory block unmovable
>>>
>>>  - the compaction is blocked for an unbounded time
>>>
>>> While the new AS_WRITEBACK_INDETERMINATE could potentially make things
>>> worse, the same thing happens on readahead, since the new page can be
>>> locked for an indeterminate amount of time, which can also block
>>> compaction, right?
>>
>> Yes locked pages are unmovable. How much of these locked pages/folios
>> can be caused by untrusted fuse server?
> 
> A stuck server would quickly reach the background threshold at which
> point everything stops.   So my guess is that accidentally this won't
> do much harm.
> 
> Doing it deliberately (tuning max_background, starting multiple
> servers) the number of pages that are permanently locked could be
> basically unlimited.

If "limiting the number of actually unmovable pages in a reasonable
bound" is acceptable, maybe we could limit the maximum number of
background requests that the whole unprivileged FUSE servers could achieve.

BTW currently the writeback requests are not limited by max_background
as the writeback routine allocates requests with "force == true".  We
had ever noticed that heavy writeback workload could starve other
background requests (e.g. readahead), in which the readahead routine
were waiting in fuse_get_req() forever until the writeback workload
finished.

-- 
Thanks,
Jingbo