From: Yafang Shao <laoar.shao@gmail.com>
To: Dave Chinner <david@fromorbit.com>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>,
Matthew Wilcox <willy@infradead.org>,
Christoph Hellwig <hch@infradead.org>,
Michal Hocko <mhocko@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
David Howells <dhowells@redhat.com>,
jlayton@redhat.com, linux-fsdevel@vger.kernel.org,
linux-cachefs@redhat.com, linux-xfs@vger.kernel.org,
Linux MM <linux-mm@kvack.org>, Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH v13 3/4] xfs: refactor the usage around xfs_trans_context_{set,clear}
Date: Sat, 19 Dec 2020 08:31:58 +0800 [thread overview]
Message-ID: <CALOAHbAAJSU5xZiNktX=z4-SHF6=xY4z8H1+VggSttFcgDeMHQ@mail.gmail.com> (raw)
In-Reply-To: <20201218000705.GR632069@dread.disaster.area>
On Fri, Dec 18, 2020 at 8:07 AM Dave Chinner <david@fromorbit.com> wrote:
>
> On Thu, Dec 17, 2020 at 03:06:27PM -0800, Darrick J. Wong wrote:
> > On Fri, Dec 18, 2020 at 09:15:09AM +1100, Dave Chinner wrote:
> > > The obvious solution: we've moved the saved process state to a
> > > different context, so it is no longer needed for the current
> > > transaction we are about to commit. So How about just clearing the
> > > saved state from the original transaction when swappingi like so:
> > >
> > > static inline void
> > > xfs_trans_context_swap(struct xfs_trans *tp, struct xfs_trans *ntp)
> > > {
> > > ntp->t_pflags = tp->t_pflags;
> > > tp->t_flags = 0;
> > > }
> > >
> > > And now, when we go to clear the transaction context, we can simply
> > > do this:
> > >
> > > static inline void
> > > xfs_trans_context_clear(struct xfs_trans *tp)
> > > {
> > > if (tp->t_pflags)
> > > memalloc_nofs_restore(tp->t_pflags);
> > > }
> > >
> > > and the problem is solved. The NOFS state will follow the active
> > > transaction and not be reset until the entire transaction chain is
> > > completed.
> >
> > Er... correct me if I'm wrong, but I thought t_pflags stores the old
> > state of current->flags from before we call xfs_trans_alloc? So if we
> > call into xfs_trans_alloc with current->flags==0 and we commit the
> > transaction having not rolled, we won't unset the _NOFS state, and exit
> > back to userspace with _NOFS set.
>
> Minor thinko.
>
> tp->t_pflags only stores a single bit of information w.r.t
> PF_MEMALLOC_NOFS state, not the entire set of current task flags:
> whether it should be cleared or not on a call to
> memalloc_nofs_restore(). See memalloc_nofs_save():
>
> static inline unsigned int memalloc_nofs_save(void)
> {
> unsigned int flags = current->flags & PF_MEMALLOC_NOFS;
> current->flags |= PF_MEMALLOC_NOFS;
> return flags;
> }
>
> So, yeah, I got the t_pflags logic the wrong way around here - zero
> means clear it, non-zero means don't clear it. IOWs, swap:
>
> ntp->t_pflags = tp->t_pflags;
> tp->t_flags = -1;
>
> and clear:
>
> if (!tp->t_flags)
> memalloc_nofs_restore(tp->t_pflags);
>
> This should only be temporary code, anyway. The next patch should
> change this state clearing check to use current->journal_info, then
> we aren't dependent on process flags state at all.
>
> > I think the logic is correct here -- we transfer the old pflags value
> > from @tp to @ntp, which effectively puts @ntp in charge of restoring the
> > old pflags value; and then we set tp->t_pflags to current->flags, which
> > means that @tp will "restore" the current pflags value into pflags, which
> > is a nop.
>
> That's pretty much what the current logic guarantees. Once the
> wrappers provide this same guarantee, we can greatly simply the the
> transaction context state management (i.e. set on alloc, swap on
> dup, clear on free). And thread handoffs can just use clear/set
> appropriately.
>
Make sense to me.
--
Thanks
Yafang
next prev parent reply other threads:[~2020-12-19 0:32 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-17 1:11 [PATCH v13 0/4] xfs: avoid transaction reservation recursion Yafang Shao
2020-12-17 1:11 ` [PATCH v13 1/4] mm: Add become_kswapd and restore_kswapd Yafang Shao
2020-12-17 3:06 ` Dave Chinner
2020-12-17 4:00 ` Matthew Wilcox
2020-12-17 4:46 ` Yafang Shao
2020-12-17 1:11 ` [PATCH v13 2/4] xfs: use memalloc_nofs_{save,restore} in xfs transaction Yafang Shao
2020-12-17 1:11 ` [PATCH v13 3/4] xfs: refactor the usage around xfs_trans_context_{set,clear} Yafang Shao
2020-12-17 22:15 ` Dave Chinner
2020-12-17 23:06 ` Darrick J. Wong
2020-12-18 0:07 ` Dave Chinner
2020-12-19 0:31 ` Yafang Shao [this message]
2020-12-19 0:28 ` Yafang Shao
2020-12-17 1:11 ` [PATCH v13 4/4] xfs: use current->journal_info to avoid transaction reservation recursion Yafang Shao
2020-12-18 0:14 ` Dave Chinner
2020-12-19 0:16 ` Yafang Shao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CALOAHbAAJSU5xZiNktX=z4-SHF6=xY4z8H1+VggSttFcgDeMHQ@mail.gmail.com' \
--to=laoar.shao@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=darrick.wong@oracle.com \
--cc=david@fromorbit.com \
--cc=dhowells@redhat.com \
--cc=hch@infradead.org \
--cc=hch@lst.de \
--cc=jlayton@redhat.com \
--cc=linux-cachefs@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-xfs@vger.kernel.org \
--cc=mhocko@kernel.org \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox