From: Wei Yang <richard.weiyang@gmail.com> To: "Huang, Ying" <ying.huang@intel.com> Cc: Wei Yang <richard.weiyang@gmail.com>, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Hugh Dickins <hughd@google.com> Subject: Re: [PATCH v2] mm/swapfile.c: simplify the scan loop in scan_swap_map_slots() Date: Wed, 29 Apr 2020 22:06:19 +0000 [thread overview] Message-ID: <20200429220619.f6xhmo7jm36xf64b@master> (raw) In-Reply-To: <874kt3xgdf.fsf@yhuang-dev.intel.com> On Wed, Apr 29, 2020 at 08:52:44AM +0800, Huang, Ying wrote: >Wei Yang <richard.weiyang@gmail.com> writes: > >> On Mon, Apr 27, 2020 at 08:55:33AM +0800, Huang, Ying wrote: >>>Wei Yang <richard.weiyang@gmail.com> writes: >>> >>>> On Sun, Apr 26, 2020 at 09:07:11AM +0800, Huang, Ying wrote: >>>>>Wei Yang <richard.weiyang@gmail.com> writes: >>>>> >>>>>> On Fri, Apr 24, 2020 at 10:02:58AM +0800, Huang, Ying wrote: >>>>>>>Wei Yang <richard.weiyang@gmail.com> writes: >>>>>>> >>>>>> [...] >>>>>>>>> >>>>>>>>>if "offset > si->highest_bit" is true and "offset < scan_base" is true, >>>>>>>>>scan_base need to be returned. >>>>>>>>> >>>>>>>> >>>>>>>> When this case would happen in the original code? >>>>>>> >>>>>>>In the original code, the loop can still stop. >>>>>>> >>>>>> >>>>>> Sorry, I don't get your point yet. >>>>>> >>>>>> In original code, there are two separate loops >>>>>> >>>>>> while (++offset <= si->highest_bit) { >>>>>> } >>>>>> >>>>>> while (offset < scan_base) { >>>>>> } >>>>>> >>>>>> And for your condition, (offset > highest_bit) && (offset < scan_base), which >>>>>> terminates the first loop and fits the second loop well. >>>>>> >>>>>> Not sure how this condition would stop the loop in original code? >>>>> >>>>>Per my understanding, in your code, if some other task changes >>>>>si->highest_bit to be less than scan_base in parallel. The loop may >>>>>cannot stop. >>>> >>>> When (offset > scan_base), (offset > si->highest_bit) means offset will be >>>> set to si->lowest_bit. >>>> >>>> When (offset < scan_base), next_offset() would always increase offset till >>>> offset is scan_base. >>>> >>>> Sorry, I didn't catch your case. Would you minding giving more detail? >>> >>>Don't think in single thread model. There's no lock to prevent other >>>tasks to change si->highest_bit simultaneously. For example, task B may >>>change si->highest_bit to be less than scan_base in task A. >>> >> >> Yes, I am trying to think about it in parallel mode. >> >> Here are the cases, it might happen in parallel when task B change highest_bit >> to be less than scan_base. >> >> (1) >> offset >> v >> +-------------------+------------------+ >> ^ ^ ^ >> lowest_bit highest_bit scan_base >> >> >> (2) >> offset >> v >> +-------------------+------------------+ >> ^ ^ ^ >> lowest_bit highest_bit scan_base >> > >This is the case in my mind. But my original understanding to your code >wasn't correct. As you said, loop can stop because offset is kept >increasing. Sorry about that. > NP. >But I still don't like your new code. It's not as obvious as the >original one. Sure, thanks for your time. > >Best Regards, >Huang, Ying > >> (3) >> offset >> v >> +-------------------+------------------+ >> ^ ^ ^ >> lowest_bit highest_bit scan_base >> >> Case (1), (offset > highest) && (offset > scan_base), offset would be set to >> lowest_bit. This looks good. >> >> Case (2), (offset > highest) && (offset < scan_base), since offset is less >> than scan_base, it wouldn't be set to lowest. Instead it will continue to >> scan_base. >> >> Case (3), almost the same as Case (2). >> >> In Case (2) and (3), one thing interesting is the loop won't stop at >> highest_bit, while the behavior is the same as original code. >> >> Maybe your concern is this one? I still not figure out your point about the >> infinite loop. Hope you would share some light on it. >> >> >>>Best Regards, >>>Huang, Ying >>> >>>>> >>>>>Best Regards, >>>>>Huang, Ying >>>>> >>>>>>>Best Regards, >>>>>>>Huang, Ying >>>>>>> >>>>>>>>>Again, the new code doesn't make it easier to find this kind of issues. >>>>>>>>> >>>>>>>>>Best Regards, >>>>>>>>>Huang, Ying -- Wei Yang Help you, Help me
prev parent reply other threads:[~2020-04-29 22:06 UTC|newest] Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-04-22 21:41 Wei Yang 2020-04-23 5:57 ` Huang, Ying 2020-04-23 13:15 ` Wei Yang 2020-04-24 2:02 ` Huang, Ying 2020-04-25 0:30 ` Wei Yang 2020-04-26 1:07 ` Huang, Ying 2020-04-26 21:19 ` Wei Yang 2020-04-27 0:55 ` Huang, Ying 2020-04-28 21:22 ` Wei Yang 2020-04-29 0:52 ` Huang, Ying 2020-04-29 22:06 ` Wei Yang [this message]
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=20200429220619.f6xhmo7jm36xf64b@master \ --to=richard.weiyang@gmail.com \ --cc=akpm@linux-foundation.org \ --cc=hughd@google.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=ying.huang@intel.com \ --subject='Re: [PATCH v2] mm/swapfile.c: simplify the scan loop in scan_swap_map_slots()' \ /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
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).