On Tue, Dec 6, 2022 at 6:20 PM Hou Tao <houtao@xxxxxxxxxxxxxxx> wrote: > > Hi, > > On 12/7/2022 9:52 AM, Yonghong Song wrote: > > > > > > On 12/5/22 8:29 PM, Hou Tao wrote: > >> From: Hou Tao <houtao1@xxxxxxxxxx> > >> > >> When there are batched freeing operations on a specific CPU, part of > >> the freed elements ((high_watermark - lower_watermark) / 2 + 1) will > >> be moved to waiting_for_gp list and the remaining part will be left in > >> free_by_rcu list and waits for the expiration of RCU-tasks-trace grace > >> period and the next invocation of free_bulk(). > > > > The change below LGTM. However, the above description seems not precise. > > IIUC, free_by_rcu list => waiting_for_gp is controlled by whether > > call_rcu_in_progress is true or not. If it is true, free_by_rcu list > > will remain intact and not moving into waiting_for_gp list. > > So it is not 'the remaining part will be left in free_by_rcu'. > > It is all elements in free_by_rcu to waiting_for_gp or none. > Thanks for the review and the suggestions. I tried to say that moving from > free_by_rcu to waiting_for_gp is slow, and there can be many free elements being > stacked on free_by_rcu list. So how about the following rephrasing or do you > still prefer "It is all elements in free_by_rcu to waiting_for_gp or none." ? > > When there are batched freeing operations on a specific CPU, part of the freed > elements ((high_watermark - lower_watermark) / 2 + 1) will be moved to > waiting_for_gp list and the remaining part will be left in free_by_rcu list. I agree with Yonghong. The above sentence is not just not precise. 'elements moved to waiting_for_gp list' part is not correct. The elements never moved into it directly. Only via free_by_rcu list. All or none also matters.
