Re: [PATCH 2/3] mm/swapfile: avoid confusing swap cache statistics

[Miaohe Lin <linmiaohe@huawei.com>]

On 2022/6/2 16:41, David Hildenbrand wrote:
> On 02.06.22 09:29, Miaohe Lin wrote:
>> On 2022/6/1 15:53, David Hildenbrand wrote:
>>> On 01.06.22 04:11, Miaohe Lin wrote:
>>>> On 2022/5/31 20:58, David Hildenbrand wrote:
>>>>> On 31.05.22 04:55, Miaohe Lin wrote:
>>>>>> On 2022/5/31 7:04, Andrew Morton wrote:
>>>>>>> On Fri, 27 May 2022 17:26:25 +0800 Miaohe Lin <linmiaohe@huawei.com> wrote:
>>>>>>>
>>>>>>>> At swapoff time, we're going to swap in the pages continuously. So calling
>>>>>>>> lookup_swap_cache would confuse statistics. We should use find_get_page
>>>>>>>> directly here.
>>>>>>>
>>>>>>> Why is the existing behaviour wrong?  swapoff() has to swap stuff in to
>>>>>>> be able to release the swap device.  Why do you believe that this
>>>>>>> swapin activity should not be accounted?
>>>>>>
>>>>>> IMHO, statistics, e.g. swap_cache_info.find_success, are used to show the effectiveness
>>>>>> of the swap cache activity. So they should only reflect the memory accessing activity
>>>>>> of the user. I think swapoff can't reflect the effectiveness of the swap cache activity
>>>>>> because it just swaps in pages one by one. Or statistics should reflect all the activity
>>>>>> of the user including swapoff?
>>>>>
>>>>> I'm wondering who cares and why?
>>>>
>>>> I thought it's used to show the effectiveness of the swapcache readahead algorithm. If nobody
>>>> ever cares about it now, I'm fine to drop this patch. And could these statistics be removed
>>>> since nobody cares about it?
>>>
>>> IIUC, they are printed (via show_swap_cache_info()), which is called via
>>> show_free_areas() -- primarily used via show_mem(). show_mem() is
>>> primarily used when OOM, when allocation fails and we warn, from the OOM
>>> killer, on panic().
>>>
>>> I am not sure how useful for (OOM ?) debugging the find_success vs.
>>> find_total stats are at all. They are from ancient times. In
>>> bb63be0a091c ("tmpfs: move swap_state stats update") we removed other
>>> statistics that are "are relics of my 2.4.11 testing". Maybe
>>> find_success and find_total can be similarly removed.
>>
>> Maybe add_total, del_total, find_success and find_total should be similarly removed altogether?
>> It seems those can't provide useful info when OOM occurs? And we can thus avoid touching the
>> swap_cache_info cacheline.
> 
> At least makes sense to me, AFAIKU, these are not statistics one could
> easily use to tune system performance because they are not easily
> accessile. Maybe simply propose removal?

I tend to agree with you. Will try to do it soon. Thanks!

> 
>