All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wei Yang <richard.weiyang@gmail.com>
To: Wei Yang <richard.weiyang@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	ying.huang@intel.com, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org
Subject: Re: [PATCH 3/3] mm/swapfile.c: count won't be bigger than SWAP_MAP_MAX
Date: Sat, 2 May 2020 13:41:38 +0000	[thread overview]
Message-ID: <20200502134138.ycm26jnxc55rimgj@master> (raw)
In-Reply-To: <20200502132911.u6y6hkh56ik4ojne@master>

On Sat, May 02, 2020 at 01:29:11PM +0000, Wei Yang wrote:
>On Fri, May 01, 2020 at 03:48:53PM -0700, Andrew Morton wrote:
>>On Fri,  1 May 2020 01:52:59 +0000 Wei Yang <richard.weiyang@gmail.com> wrote:
>>
>>> When the condition is true, there are two possibilities:
>>
>>I'm struggling with this one.
>>
>>>    1. count == SWAP_MAP_BAD
>>>    2. count == (SWAP_MAP_MAX & COUNT_CONTINUED) == SWAP_MAP_SHMEM
>>
>>I'm not sure what 2. is trying to say.  For a start, (SWAP_MAP_MAX &
>>COUNT_CONTINUED) is zero.  I guess it meant "|"?
>
>Oops, you are right. It should be (SWAP_MAP_MAX | COUNT_CONTINUED).
>
>Sorry for the confusion.
>

Hmm... I made a mistake again, the two cases should be

  * SWAP_MAP_BAD
  * (SWAP_MAP_BAD | COUNT_CONTINUED) == SWAP_MAP_SHMEM

What a shame.

>>
>>Also, the return value documentation says we return EINVAL for migration
>>entries.  Where's that happening, or is the comment out of date?
>>
>
>Not paid attention to this.
>
>Take look into the code, I don't find a relationship between the swap count
>and migration. Seems we just make a migration entry but not duplicate it.  
>If my understanding is correct.
>
>>> The first case would be filtered by the first if in __swap_duplicate().
>>> 
>>> And the second case means this swap entry is for shmem. Since we never
>>> do another duplication for shmem swap entry. This won't happen neither.
>>
>
>-- 
>Wei Yang
>Help you, Help me

-- 
Wei Yang
Help you, Help me

  reply	other threads:[~2020-05-02 13:41 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-01  1:52 [PATCH 1/3] mm/swapfile.c: classify SWAP_MAP_XXX to make it more readable Wei Yang
2020-05-01  1:52 ` [PATCH 2/3] mm/swapfile.c: __swap_entry_free() always free 1 entry Wei Yang
2020-05-01  1:52 ` [PATCH 3/3] mm/swapfile.c: count won't be bigger than SWAP_MAP_MAX Wei Yang
2020-05-01 22:48   ` Andrew Morton
2020-05-02 13:29     ` Wei Yang
2020-05-02 13:41       ` Wei Yang [this message]
2020-05-06  8:22       ` Huang, Ying
2020-05-06  8:22         ` Huang, Ying
2020-05-07 22:20         ` Wei Yang
2020-05-07 23:48           ` Huang, Ying
2020-05-07 23:48             ` Huang, Ying
2020-05-08 21:19             ` Wei Yang

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=20200502134138.ycm26jnxc55rimgj@master \
    --to=richard.weiyang@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.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 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.