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

[Jan Kara <jack@suse.cz>]

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