From: Vineeth Pillai <vpillai@digitalocean.com>
To: Hugh Dickins <hughd@google.com>
Cc: Matthew Wilcox <willy@infradead.org>,
Andrew Morton <akpm@linux-foundation.org>,
Huang Ying <ying.huang@intel.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Kelley Nielsen <kelleynnn@gmail.com>,
Rik van Riel <riel@surriel.com>
Subject: Re: [PATCH v3 2/2] mm: rid swapoff of quadratic complexity
Date: Wed, 2 Jan 2019 12:47:43 -0500 [thread overview]
Message-ID: <CANaguZC_d2EBmNuXtcJRcEcw8uXK234tYSXx6Uc2o9JH_vfP4A@mail.gmail.com> (raw)
In-Reply-To: <alpine.LSU.2.11.1901012010440.13241@eggly.anvils>
On Tue, Jan 1, 2019 at 11:16 PM Hugh Dickins <hughd@google.com> wrote:
> One more fix on top of what I sent yesterday: once I delved into
> the retries, I found that the major cause of exceeding MAX_RETRIES
> was the way the retry code neatly avoided retrying the last part of
> its work. With this fix in, I have not yet seen retries go above 1:
> no doubt it could, but at present I have no actual evidence that
> the MAX_RETRIES-or-livelock issue needs to be dealt with urgently.
> Fix sent for completeness, but it reinforces the point that the
> structure of try_to_unuse() should be reworked, and oldi gone.
>
Thanks for the fix and suggestions Hugh!
After reading the code again, I feel like we can make the retry logic
simpler and avoid the use of oldi. If my understanding is correct,
except for frontswap case, we reach try_to_unuse() only after we
disable the swap device. So I think, we would not be seeing any more
swap usage on the disabled swap device, after we loop through all the
process and swapin the pages on that device. In that case, we would
not need the retry logic right?
For frontswap case, the patch was missing a check for pages_to_unuse.
We would still need the retry logic, but as you mentioned, I can
easily remove the oldi logic and make it simpler. Or probably,
refactor the frontswap code out as a special case if pages_to_unuse is
still not zero after the initial loop.
Thanks,
Vineeth
next prev parent reply other threads:[~2019-01-02 17:47 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-03 17:09 [PATCH v3 1/2] mm: Refactor swap-in logic out of shmem_getpage_gfp Vineeth Remanan Pillai
2018-12-03 17:09 ` [PATCH v3 2/2] mm: rid swapoff of quadratic complexity Vineeth Remanan Pillai
2019-01-01 0:44 ` Hugh Dickins
2019-01-01 0:44 ` Hugh Dickins
2019-01-01 18:24 ` Vineeth Pillai
2019-01-01 18:24 ` Vineeth Pillai
2019-01-02 4:16 ` Hugh Dickins
2019-01-02 4:16 ` Hugh Dickins
2019-01-02 17:47 ` Vineeth Pillai [this message]
2019-01-02 17:47 ` Vineeth Pillai
2019-01-02 19:43 ` Hugh Dickins
2019-01-02 19:43 ` Hugh Dickins
2019-01-02 20:05 ` Vineeth Pillai
2019-01-02 20:05 ` Vineeth Pillai
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=CANaguZC_d2EBmNuXtcJRcEcw8uXK234tYSXx6Uc2o9JH_vfP4A@mail.gmail.com \
--to=vpillai@digitalocean.com \
--cc=akpm@linux-foundation.org \
--cc=hughd@google.com \
--cc=kelleynnn@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=riel@surriel.com \
--cc=willy@infradead.org \
--cc=ying.huang@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox