From: Sasha Levin <levinsasha928@gmail.com>
To: Minchan Kim <minchan@kernel.org>
Cc: dan.magenheimer@oracle.com, konrad.wilk@oracle.com,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 04/10] mm: frontswap: split out __frontswap_unuse_pages
Date: Mon, 11 Jun 2012 12:30:50 +0200 [thread overview]
Message-ID: <1339410650.4999.38.camel@lappy> (raw)
In-Reply-To: <4FD5856C.5060708@kernel.org>
On Mon, 2012-06-11 at 14:43 +0900, Minchan Kim wrote:
> On 06/10/2012 07:51 PM, Sasha Levin wrote:
>
> > An attempt at making frontswap_shrink shorter and more readable. This patch
> > splits out walking through the swap list to find an entry with enough
> > pages to unuse.
> >
> > Also, assert that the internal __frontswap_unuse_pages is called under swap
> > lock, since that part of code was previously directly happen inside the lock.
> >
> > Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
> > ---
> > mm/frontswap.c | 59 +++++++++++++++++++++++++++++++++++++-------------------
> > 1 files changed, 39 insertions(+), 20 deletions(-)
> >
> > diff --git a/mm/frontswap.c b/mm/frontswap.c
> > index 5faf840..faa43b7 100644
> > --- a/mm/frontswap.c
> > +++ b/mm/frontswap.c
> > @@ -230,6 +230,41 @@ static unsigned long __frontswap_curr_pages(void)
> > return totalpages;
> > }
> >
> > +static int __frontswap_unuse_pages(unsigned long total, unsigned long *unused,
> > + int *swapid)
>
>
> Normally, we use "unsigned int type" instead of swapid.
> I admit the naming is rather awkward but that should be another patch.
> So let's keep consistency with swap subsystem.
I was staying consistent with the naming in mm/frontswap.c. I'll add an
extra patch to modify it to be similar to what's being used in the rest
of the swap subsystem.
> > +{
> > + int ret = -EINVAL;
> > + struct swap_info_struct *si = NULL;
> > + int si_frontswap_pages;
> > + unsigned long total_pages_to_unuse = total;
> > + unsigned long pages = 0, pages_to_unuse = 0;
> > + int type;
> > +
> > + assert_spin_locked(&swap_lock);
>
>
> Normally, we should use this assertion when we can't find swap_lock is hold or not easily
> by complicated call depth or unexpected use-case like general function.
> But I expect this function's caller is very limited, not complicated.
> Just comment write down isn't enough?
Is there a reason not to do it though? Debugging a case where this
function is called without a swaplock and causes corruption won't be
easy.
> > + for (type = swap_list.head; type >= 0; type = si->next) {
> > + si = swap_info[type];
> > + si_frontswap_pages = atomic_read(&si->frontswap_pages);
> > + if (total_pages_to_unuse < si_frontswap_pages) {
> > + pages = pages_to_unuse = total_pages_to_unuse;
> > + } else {
> > + pages = si_frontswap_pages;
> > + pages_to_unuse = 0; /* unuse all */
> > + }
> > + /* ensure there is enough RAM to fetch pages from frontswap */
> > + if (security_vm_enough_memory_mm(current->mm, pages)) {
> > + ret = -ENOMEM;
>
>
> Nipick:
> I am not sure detailed error returning would be good.
> Caller doesn't matter it now but it can consider it in future.
> Hmm,
Is there a reason to avoid returning a meaningful error when it's pretty
easy?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Sasha Levin <levinsasha928@gmail.com>
To: Minchan Kim <minchan@kernel.org>
Cc: dan.magenheimer@oracle.com, konrad.wilk@oracle.com,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 04/10] mm: frontswap: split out __frontswap_unuse_pages
Date: Mon, 11 Jun 2012 12:30:50 +0200 [thread overview]
Message-ID: <1339410650.4999.38.camel@lappy> (raw)
In-Reply-To: <4FD5856C.5060708@kernel.org>
On Mon, 2012-06-11 at 14:43 +0900, Minchan Kim wrote:
> On 06/10/2012 07:51 PM, Sasha Levin wrote:
>
> > An attempt at making frontswap_shrink shorter and more readable. This patch
> > splits out walking through the swap list to find an entry with enough
> > pages to unuse.
> >
> > Also, assert that the internal __frontswap_unuse_pages is called under swap
> > lock, since that part of code was previously directly happen inside the lock.
> >
> > Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
> > ---
> > mm/frontswap.c | 59 +++++++++++++++++++++++++++++++++++++-------------------
> > 1 files changed, 39 insertions(+), 20 deletions(-)
> >
> > diff --git a/mm/frontswap.c b/mm/frontswap.c
> > index 5faf840..faa43b7 100644
> > --- a/mm/frontswap.c
> > +++ b/mm/frontswap.c
> > @@ -230,6 +230,41 @@ static unsigned long __frontswap_curr_pages(void)
> > return totalpages;
> > }
> >
> > +static int __frontswap_unuse_pages(unsigned long total, unsigned long *unused,
> > + int *swapid)
>
>
> Normally, we use "unsigned int type" instead of swapid.
> I admit the naming is rather awkward but that should be another patch.
> So let's keep consistency with swap subsystem.
I was staying consistent with the naming in mm/frontswap.c. I'll add an
extra patch to modify it to be similar to what's being used in the rest
of the swap subsystem.
> > +{
> > + int ret = -EINVAL;
> > + struct swap_info_struct *si = NULL;
> > + int si_frontswap_pages;
> > + unsigned long total_pages_to_unuse = total;
> > + unsigned long pages = 0, pages_to_unuse = 0;
> > + int type;
> > +
> > + assert_spin_locked(&swap_lock);
>
>
> Normally, we should use this assertion when we can't find swap_lock is hold or not easily
> by complicated call depth or unexpected use-case like general function.
> But I expect this function's caller is very limited, not complicated.
> Just comment write down isn't enough?
Is there a reason not to do it though? Debugging a case where this
function is called without a swaplock and causes corruption won't be
easy.
> > + for (type = swap_list.head; type >= 0; type = si->next) {
> > + si = swap_info[type];
> > + si_frontswap_pages = atomic_read(&si->frontswap_pages);
> > + if (total_pages_to_unuse < si_frontswap_pages) {
> > + pages = pages_to_unuse = total_pages_to_unuse;
> > + } else {
> > + pages = si_frontswap_pages;
> > + pages_to_unuse = 0; /* unuse all */
> > + }
> > + /* ensure there is enough RAM to fetch pages from frontswap */
> > + if (security_vm_enough_memory_mm(current->mm, pages)) {
> > + ret = -ENOMEM;
>
>
> Nipick:
> I am not sure detailed error returning would be good.
> Caller doesn't matter it now but it can consider it in future.
> Hmm,
Is there a reason to avoid returning a meaningful error when it's pretty
easy?
next prev parent reply other threads:[~2012-06-11 10:29 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-10 10:50 [PATCH v3 00/10] minor frontswap cleanups and tracing support Sasha Levin
2012-06-10 10:50 ` Sasha Levin
2012-06-10 10:50 ` [PATCH v3 01/10] mm: frontswap: remove casting from function calls through ops structure Sasha Levin
2012-06-10 10:50 ` Sasha Levin
2012-06-11 5:20 ` Minchan Kim
2012-06-11 5:20 ` Minchan Kim
2012-06-10 10:51 ` [PATCH v3 02/10] mm: frontswap: trivial coding convention issues Sasha Levin
2012-06-10 10:51 ` Sasha Levin
2012-06-11 5:24 ` Minchan Kim
2012-06-11 5:24 ` Minchan Kim
2012-06-10 10:51 ` [PATCH v3 03/10] mm: frontswap: split out __frontswap_curr_pages Sasha Levin
2012-06-10 10:51 ` Sasha Levin
2012-06-11 5:28 ` Minchan Kim
2012-06-11 5:28 ` Minchan Kim
2012-06-10 10:51 ` [PATCH v3 04/10] mm: frontswap: split out __frontswap_unuse_pages Sasha Levin
2012-06-10 10:51 ` Sasha Levin
2012-06-11 5:43 ` Minchan Kim
2012-06-11 5:43 ` Minchan Kim
2012-06-11 10:30 ` Sasha Levin [this message]
2012-06-11 10:30 ` Sasha Levin
2012-06-11 14:27 ` Dan Magenheimer
2012-06-11 14:27 ` Dan Magenheimer
2012-06-11 14:31 ` Konrad Rzeszutek Wilk
2012-06-11 14:31 ` Konrad Rzeszutek Wilk
2012-06-11 14:38 ` Sasha Levin
2012-06-11 14:38 ` Sasha Levin
2012-06-10 10:51 ` [PATCH v3 05/10] mm: frontswap: split frontswap_shrink further to simplify locking Sasha Levin
2012-06-10 10:51 ` Sasha Levin
2012-06-11 5:49 ` Minchan Kim
2012-06-11 5:49 ` Minchan Kim
2012-06-10 10:51 ` [PATCH v3 06/10] mm: frontswap: make all branches of if statement in put page consistent Sasha Levin
2012-06-10 10:51 ` Sasha Levin
2012-06-11 5:52 ` Minchan Kim
2012-06-11 5:52 ` Minchan Kim
2012-06-10 10:51 ` [PATCH v3 07/10] mm: frontswap: remove unnecessary check during initialization Sasha Levin
2012-06-10 10:51 ` Sasha Levin
2012-06-11 5:54 ` Minchan Kim
2012-06-11 5:54 ` Minchan Kim
2012-06-10 10:51 ` [PATCH v3 08/10] mm: frontswap: add tracing support Sasha Levin
2012-06-10 10:51 ` Sasha Levin
2012-06-11 6:12 ` Minchan Kim
2012-06-11 6:12 ` Minchan Kim
2012-06-11 8:33 ` Pekka Enberg
2012-06-11 8:33 ` Pekka Enberg
2012-06-11 10:39 ` Sasha Levin
2012-06-11 10:39 ` Sasha Levin
2012-06-10 10:51 ` [PATCH v3 09/10] mm: frontswap: split out function to clear a page out Sasha Levin
2012-06-10 10:51 ` Sasha Levin
2012-06-11 6:16 ` Minchan Kim
2012-06-11 6:16 ` Minchan Kim
2012-06-10 10:51 ` [PATCH v3 10/10] mm: frontswap: remove unneeded headers Sasha Levin
2012-06-10 10:51 ` Sasha Levin
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=1339410650.4999.38.camel@lappy \
--to=levinsasha928@gmail.com \
--cc=dan.magenheimer@oracle.com \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=minchan@kernel.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 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.