linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Tim Chen <tim.c.chen@linux.intel.com>
To: Andrew Morton <akpm@linux-foundation.org>,
	Wei Yang <richard.weiyang@linux.alibaba.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm/swap_slots.c: don't reset the cache slot after use
Date: Tue, 10 Mar 2020 11:13:13 -0700	[thread overview]
Message-ID: <005f7454-16db-e8b5-dde2-8f2ddaa42932@linux.intel.com> (raw)
In-Reply-To: <20200309174854.b6b8c7f019c3dde048c28f94@linux-foundation.org>

On 3/9/20 5:48 PM, Andrew Morton wrote:
> On Mon,  9 Mar 2020 17:09:40 +0800 Wei Yang <richard.weiyang@linux.alibaba.com> wrote:
> 
>> Currently we would clear the cache slot if it is used. While this is not
>> necessary, since this entry would not be used until refilled.
>>
>> Leave it untouched and assigned the value directly to entry which makes
>> the code little more neat.
>>
>> Also this patch merges the else and if, since this is the only case we
>> refill and repeat swap cache.
> 
> cc Tim, who can hopefully remember how this code works ;)
> 
>> --- a/mm/swap_slots.c
>> +++ b/mm/swap_slots.c
>> @@ -309,7 +309,7 @@ int free_swap_slot(swp_entry_t entry)
>>  
>>  swp_entry_t get_swap_page(struct page *page)
>>  {
>> -	swp_entry_t entry, *pentry;
>> +	swp_entry_t entry;
>>  	struct swap_slots_cache *cache;
>>  
>>  	entry.val = 0;
>> @@ -336,13 +336,10 @@ swp_entry_t get_swap_page(struct page *page)
>>  		if (cache->slots) {
>>  repeat:
>>  			if (cache->nr) {
>> -				pentry = &cache->slots[cache->cur++];
>> -				entry = *pentry;
>> -				pentry->val = 0;

The cache entry was cleared after assignment for defensive programming,  So there's
little chance I will be using a slot that has been assigned to someone else.
When I wrote swap_slots.c, this code was new and I want to make sure
that if something went wrong, and I assigned a swap slot that I shouldn't,
I will be able to detect quickly as I will only be stepping on entry 0.

Otherwise such bug will be harder to detect as we will have two users of some random
swap slot stepping on each other.

I'm okay if we want to get rid of this logic, now that the code has been
working correctly long enough.  But I think is good hygiene to clear the
cached entry after it has been assigned. 

>> +				entry = cache->slots[cache->cur++];
>>  				cache->nr--;
>> -			} else {
>> -				if (refill_swap_slots_cache(cache))
>> -					goto repeat;
>> +			} else if (refill_swap_slots_cache(cache)) {

This change looks fine.
>> +				goto repeat;
>>  			}

Tim


  reply	other threads:[~2020-03-10 18:13 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-09  9:09 [PATCH] mm/swap_slots.c: don't reset the cache slot after use Wei Yang
2020-03-10  0:48 ` Andrew Morton
2020-03-10 18:13   ` Tim Chen [this message]
2020-03-10 22:20     ` Wei Yang
2020-03-10 23:03       ` Tim Chen
2020-03-11  1:17         ` 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=005f7454-16db-e8b5-dde2-8f2ddaa42932@linux.intel.com \
    --to=tim.c.chen@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=richard.weiyang@linux.alibaba.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;
as well as URLs for NNTP newsgroup(s).