Re: [RFC PATCH v3 15/18] mm: Add balance_dirty_pages_ratelimited_async() function

Jan Kara
2022-05-19T08:54:16Z

On Thu 19-05-22 01:29:21, Christoph Hellwig wrote:
> > +static int balance_dirty_pages_ratelimited_flags(struct address_space *mapping,
> > + bool no_wait)
> > {
>
> This doesn't actully take flags, but a single boolean argument. So
> either it needs a new name, or we actually pass a descriptiv flag.
>
> > +/**
> > + * balance_dirty_pages_ratelimited_async - balance dirty memory state
> > + * @mapping: address_space which was dirtied
> > + *
> > + * Processes which are dirtying memory should call in here once for each page
> > + * which was newly dirtied. The function will periodically check the system's
> > + * dirty state and will initiate writeback if needed.
> > + *
> > + * Once we're over the dirty memory limit we decrease the ratelimiting
> > + * by a lot, to prevent individual processes from overshooting the limit
> > + * by (ratelimit_pages) each.
> > + *
> > + * This is the async version of the API. It only checks if it is required to
> > + * balance dirty pages. In case it needs to balance dirty pages, it returns
> > + * -EAGAIN.
> > + */
> > +int balance_dirty_pages_ratelimited_async(struct address_space *mapping)
> > +{
> > + return balance_dirty_pages_ratelimited_flags(mapping, true);
> > +}
> > +EXPORT_SYMBOL(balance_dirty_pages_ratelimited_async);
>
> I'd much rather export the underlying
> balance_dirty_pages_ratelimited_flags helper than adding a pointless
> wrapper here. And as long as only iomap is supported there is no need
> to export it at all.

This was actually my suggestion so I take the blame ;) I have suggested
this because I don't like non-static functions with bool arguments (it is
unnecessarily complicated to understand what the argument means or grep for
it etc.). If you don't like the wrapper, creating

int balance_dirty_pages_ratelimited_flags(struct address_space *mapping,
unsigned int flags)

and have something like:

#define BDP_NOWAIT 0x0001

is fine with me as well.

Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR