From: Richard Weinberger <richard@nod.at>
To: "Kirill A. Shutemov" <kirill@shutemov.name>
Cc: zhangjun <openzhangj@gmail.com>,
Artem Bityutskiy <dedekind1@gmail.com>,
Adrian Hunter <adrian.hunter@intel.com>,
linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
kirill.shutemov@linux.intel.com, hch@lst.de,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH v2] ubifs: fix page_count in ->ubifs_migrate_page()
Date: Thu, 13 Dec 2018 23:08:08 +0100 [thread overview]
Message-ID: <1683588.PnVoaTFAp1@blindfold> (raw)
In-Reply-To: <20181213220000.7b56wysed67y5iv6@kshutemo-mobl1>
Am Donnerstag, 13. Dezember 2018, 23:00:00 CET schrieb Kirill A. Shutemov:
> > Let's wait a few days to give Kirill a chance to review, then I'll apply the patch.
>
> I don't remmeber much context now...
>
> Could you remind me why ubifs doesn't take additional pin when sets
> PG_private?
Because it does not use set_page_private(), it just sets the flag for
internal accounting purposes.
>From UBIFS docs:
* UBIFS uses 2 page flags: @PG_private and @PG_checked. @PG_private is set if
* the page is dirty and is used for optimization purposes - dirty pages are
* not budgeted so the flag shows that 'ubifs_write_end()' should not release
* the budget for this page. The @PG_checked flag is set if full budgeting is
* required for the page e.g., when it corresponds to a file hole or it is
* beyond the file size. The budgeting is done in 'ubifs_write_begin()', because
* it is OK to fail in this function, and the budget is released in
* 'ubifs_write_end()'. So the @PG_private and @PG_checked flags carry
* information about how the page was budgeted, to make it possible to release
* the budget properly.
> Migration is not the only place where the additional pin is implied.
> See all users of page_has_private() helper. Notably reclaim path.
Hmmm, I need to dig into that.
I this is a problem then f2fs suffers from it too.
At least from what I can tell from reading f2fs_migrate_page().
Thanks,
//richard
WARNING: multiple messages have this Message-ID (diff)
From: Richard Weinberger <richard@nod.at>
To: "Kirill A. Shutemov" <kirill@shutemov.name>
Cc: zhangjun <openzhangj@gmail.com>,
Artem Bityutskiy <dedekind1@gmail.com>,
Adrian Hunter <adrian.hunter@intel.com>,
linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
kirill.shutemov@linux.intel.com, hch@lst.de,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH v2] ubifs: fix page_count in ->ubifs_migrate_page()
Date: Thu, 13 Dec 2018 23:08:08 +0100 [thread overview]
Message-ID: <1683588.PnVoaTFAp1@blindfold> (raw)
In-Reply-To: <20181213220000.7b56wysed67y5iv6@kshutemo-mobl1>
Am Donnerstag, 13. Dezember 2018, 23:00:00 CET schrieb Kirill A. Shutemov:
> > Let's wait a few days to give Kirill a chance to review, then I'll apply the patch.
>
> I don't remmeber much context now...
>
> Could you remind me why ubifs doesn't take additional pin when sets
> PG_private?
Because it does not use set_page_private(), it just sets the flag for
internal accounting purposes.
From UBIFS docs:
* UBIFS uses 2 page flags: @PG_private and @PG_checked. @PG_private is set if
* the page is dirty and is used for optimization purposes - dirty pages are
* not budgeted so the flag shows that 'ubifs_write_end()' should not release
* the budget for this page. The @PG_checked flag is set if full budgeting is
* required for the page e.g., when it corresponds to a file hole or it is
* beyond the file size. The budgeting is done in 'ubifs_write_begin()', because
* it is OK to fail in this function, and the budget is released in
* 'ubifs_write_end()'. So the @PG_private and @PG_checked flags carry
* information about how the page was budgeted, to make it possible to release
* the budget properly.
> Migration is not the only place where the additional pin is implied.
> See all users of page_has_private() helper. Notably reclaim path.
Hmmm, I need to dig into that.
I this is a problem then f2fs suffers from it too.
At least from what I can tell from reading f2fs_migrate_page().
Thanks,
//richard
next prev parent reply other threads:[~2018-12-13 22:08 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-13 19:20 [PATCH v2] ubifs: fix page_count in ->ubifs_migrate_page() zhangjun
2018-12-13 21:36 ` Richard Weinberger
2018-12-13 22:00 ` Kirill A. Shutemov
2018-12-13 22:08 ` Richard Weinberger [this message]
2018-12-13 22:08 ` Richard Weinberger
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=1683588.PnVoaTFAp1@blindfold \
--to=richard@nod.at \
--cc=adrian.hunter@intel.com \
--cc=dedekind1@gmail.com \
--cc=hch@lst.de \
--cc=kirill.shutemov@linux.intel.com \
--cc=kirill@shutemov.name \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=openzhangj@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.