From: Dave Chinner <david@fromorbit.com>
To: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: Yafang Shao <laoar.shao@gmail.com>,
willy@infradead.org, hch@infradead.org, mhocko@kernel.org,
akpm@linux-foundation.org, dhowells@redhat.com,
jlayton@redhat.com, linux-fsdevel@vger.kernel.org,
linux-cachefs@redhat.com, linux-xfs@vger.kernel.org,
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: Fri, 18 Dec 2020 11:07:05 +1100 [thread overview]
Message-ID: <20201218000705.GR632069@dread.disaster.area> (raw)
In-Reply-To: <20201217230627.GB6911@magnolia>
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.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2020-12-18 0:07 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 [this message]
2020-12-19 0:31 ` Yafang Shao
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=20201218000705.GR632069@dread.disaster.area \
--to=david@fromorbit.com \
--cc=akpm@linux-foundation.org \
--cc=darrick.wong@oracle.com \
--cc=dhowells@redhat.com \
--cc=hch@infradead.org \
--cc=hch@lst.de \
--cc=jlayton@redhat.com \
--cc=laoar.shao@gmail.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