Re: [Cluster-devel] [PATCH v3 11/23] f2fs: Convert f2fs_fsync_node_pages() to use filemap_get_folios_tag()
On Mon, Oct 24, 2022 at 12:31 PM Vishal Moola wrote:
>
> On Mon, Oct 17, 2022 at 1:25 PM Vishal Moola (Oracle)
> wrote:
> >
> > Convert function to use a folio_batch instead of pagevec. This is in
> > preparation for the removal of find_get_pages_range_tag().
> >
> > Signed-off-by: Vishal Moola (Oracle)
> > ---
> > fs/f2fs/node.c | 19 ++-
> > 1 file changed, 10 insertions(+), 9 deletions(-)
> >
> > diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
> > index 983572f23896..e8b72336c096 100644
> > --- a/fs/f2fs/node.c
> > +++ b/fs/f2fs/node.c
> > @@ -1728,12 +1728,12 @@ int f2fs_fsync_node_pages(struct f2fs_sb_info *sbi,
> > struct inode *inode,
> > unsigned int *seq_id)
> > {
> > pgoff_t index;
> > - struct pagevec pvec;
> > + struct folio_batch fbatch;
> > int ret = 0;
> > struct page *last_page = NULL;
> > bool marked = false;
> > nid_t ino = inode->i_ino;
> > - int nr_pages;
> > + int nr_folios;
> > int nwritten = 0;
> >
> > if (atomic) {
> > @@ -1742,20 +1742,21 @@ int f2fs_fsync_node_pages(struct f2fs_sb_info *sbi,
> > struct inode *inode,
> > return PTR_ERR_OR_ZERO(last_page);
> > }
> > retry:
> > - pagevec_init();
> > + folio_batch_init();
> > index = 0;
> >
> > - while ((nr_pages = pagevec_lookup_tag(, NODE_MAPPING(sbi),
> > ,
> > - PAGECACHE_TAG_DIRTY))) {
> > + while ((nr_folios = filemap_get_folios_tag(NODE_MAPPING(sbi),
> > ,
> > + (pgoff_t)-1, PAGECACHE_TAG_DIRTY,
> > + ))) {
> > int i;
> >
> > - for (i = 0; i < nr_pages; i++) {
> > - struct page *page = pvec.pages[i];
> > + for (i = 0; i < nr_folios; i++) {
> > + struct page *page = [i]->page;
> > bool submitted = false;
> >
> > if (unlikely(f2fs_cp_error(sbi))) {
> > f2fs_put_page(last_page, 0);
> > - pagevec_release();
> > + folio_batch_release();
> > ret = -EIO;
> > goto out;
> > }
> > @@ -1821,7 +1822,7 @@ int f2fs_fsync_node_pages(struct f2fs_sb_info *sbi,
> > struct inode *inode,
> > break;
> > }
> > }
> > - pagevec_release();
> > + folio_batch_release();
> > cond_resched();
> >
> > if (ret || marked)
> > --
> > 2.36.1
> >
>
> Following up on these f2fs patches (11/23, 12/23, 13/23, 14/23, 15/23,
> 16/23). Does anyone have time to review them this week?
Chao, thank you for taking a look at some of these patches!
If you have time to look over the remaining patches (14, 15, 16)
feedback on those would be appreciated as well.
Re: [Cluster-devel] [PATCHv2] mm: slab: comment __GFP_ZERO case for kmem_cache_alloc
Hi, On Thu, Nov 10, 2022 at 3:37 AM Vlastimil Babka wrote: ... > > So, I did the following, which IMHO resolves the misleading parts and also > mentions __GFP_ZERO. Sounds OK? > > https://git.kernel.org/pub/scm/linux/kernel/git/vbabka/slab.git/commit/?h=slab/for-6.2/cleanups=d6a3a7c3f65dfebcbc4872d5912d3465c8e8b051 > perfect, thanks! - Alex
Re: [Cluster-devel] [PATCHv2] mm: slab: comment __GFP_ZERO case for kmem_cache_alloc
On 10/14/22 13:59, Alexander Aring wrote: > Hi, > > On Fri, Oct 14, 2022 at 3:35 AM Vlastimil Babka wrote: >> >> On 10/11/22 16:54, Alexander Aring wrote: >> > This patch will add a comment for the __GFP_ZERO flag case for >> > kmem_cache_alloc(). As the current comment mentioned that the flags only >> > matters if the cache has no available objects it's different for the >> > __GFP_ZERO flag which will ensure that the returned object is always >> > zeroed in any case. >> > >> > I have the feeling I run into this question already two times if the >> > user need to zero the object or not, but the user does not need to zero >> > the object afterwards. However another use of __GFP_ZERO and only zero >> > the object if the cache has no available objects would also make no >> > sense. >> >> Hmm, but even with the update, the comment is still rather misleading, no? >> - can the caller know if the cache has available objects and thus the flags >> are irrelevant, in order to pass flags that are potentially wrong (if there >> were no objects)? Not really. > > No, the caller cannot know it and that's why __GFP_ZERO makes no sense > if they matter only if the cache has no available objects. > >> - even if cache has available objects, we'll always end up in >> slab_pre_alloc_hook doing might_alloc(flags) which will trigger warnings >> (given CONFIG_DEBUG_ATOMIC_SLEEP etc.) if the flags are inappropriate for >> given context. So they are still "relevant" >> > > yes, so they are _always_ relevant in the current implementation. Also > as you said the user doesn't know when they become relevant or not.. > >> So maybe just delete the whole comment? slub.c doesn't have it, and if any >> such comment should exist for kmem_cache_alloc() and contain anything useful >> and not misleading, it should be probably in include/linux/slab.h anyway? >> > > ctags brought me there, but this isn't a real argument why it should > not be in the header file... > > I am not sure about deleting the whole comment as people have an vague > idea about how kmem_cache works and still need to know for __GFP_ZERO > that it will always zero the memory, but thinking again somebody will > make the conclusion it does not make sense as the user doesn't know > when objects are reused or allocated. Having that in mind and reading > the current comment was making me do more investigations into the > internal behaviour to figure out how it works regarding __GFP_ZERO. So, I did the following, which IMHO resolves the misleading parts and also mentions __GFP_ZERO. Sounds OK? https://git.kernel.org/pub/scm/linux/kernel/git/vbabka/slab.git/commit/?h=slab/for-6.2/cleanups=d6a3a7c3f65dfebcbc4872d5912d3465c8e8b051
