[PATCH] mm/vmscan: remove prefetch_prev_lru_page

[PATCH] mm/vmscan: remove prefetch_prev_lru_page

[Alex Shi]

This macro are never used in git history. So better to remove.

Signed-off-by: Alex Shi <alex.shi@linux.alibaba.com>
Cc: Andrew Morton <akpm@linux-foundation.org> 
Cc: linux-mm@kvack.org 
Cc: linux-kernel@vger.kernel.org 
---
 mm/vmscan.c | 14 --------------
 1 file changed, 14 deletions(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index 4e699ed3501e..033e7145061b 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -146,20 +146,6 @@ struct scan_control {
 	struct reclaim_state reclaim_state;
 };
 
-#ifdef ARCH_HAS_PREFETCH
-#define prefetch_prev_lru_page(_page, _base, _field)			\
-	do {								\
-		if ((_page)->lru.prev != _base) {			\
-			struct page *prev;				\
-									\
-			prev = lru_to_page(&(_page->lru));		\
-			prefetch(&prev->_field);			\
-		}							\
-	} while (0)
-#else
-#define prefetch_prev_lru_page(_page, _base, _field) do { } while (0)
-#endif
-
 #ifdef ARCH_HAS_PREFETCHW
 #define prefetchw_prev_lru_page(_page, _base, _field)			\
 	do {								\
-- 
1.8.3.1

Re: [PATCH] mm/vmscan: remove prefetch_prev_lru_page

[Qian Cai]

> On Jan 14, 2020, at 7:55 AM, Alex Shi <alex.shi@linux.alibaba.com> wrote:
> 
> This macro are never used in git history. So better to remove.

When removing unused thingy, it is important to figure out which commit introduced it in the first place and Cc the relevant people in that commit.

Re: [PATCH] mm/vmscan: remove prefetch_prev_lru_page

[Alex Shi]

在 2020/1/14 下午9:46, Qian Cai 写道:
> 
> 
>> On Jan 14, 2020, at 7:55 AM, Alex Shi <alex.shi@linux.alibaba.com> wrote:
>>
>> This macro are never used in git history. So better to remove.
> 
> When removing unused thingy, it is important to figure out which commit introduced it in the first place and Cc the relevant people in that commit.
> 

Thanks fore reminder, Qian!

This macro was introduced in 1da177e4c3f4 Linux-2.6.12-rc2, no author or commiter could be found.

Thanks
Alex

Re: [PATCH] mm/vmscan: remove prefetch_prev_lru_page

[Christoph Hellwig]

On Tue, Jan 14, 2020 at 08:46:21AM -0500, Qian Cai wrote:
> 
> 
> > On Jan 14, 2020, at 7:55 AM, Alex Shi <alex.shi@linux.alibaba.com> wrote:
> > 
> > This macro are never used in git history. So better to remove.
> 
> When removing unused thingy, it is important to figure out which commit introduced it in the first place and Cc the relevant people in that commit.

No, it isn't.  It is at best nice to have, but for a trivial macro
really doesn't matter.

Re: [PATCH] mm/vmscan: remove prefetch_prev_lru_page

[Qian Cai]

> On Jan 15, 2020, at 3:29 AM, Christoph Hellwig <hch@infradead.org> wrote:
> 
> On Tue, Jan 14, 2020 at 08:46:21AM -0500, Qian Cai wrote:
>> 
>> 
>>> On Jan 14, 2020, at 7:55 AM, Alex Shi <alex.shi@linux.alibaba.com> wrote:
>>> 
>>> This macro are never used in git history. So better to remove.
>> 
>> When removing unused thingy, it is important to figure out which commit introduced it in the first place and Cc the relevant people in that commit.
> 
> No, it isn't.  It is at best nice to have, but for a trivial macro
> really doesn't matter.

A more of personal taste what the trivial macro is. I’d rather be on the caution side
when removing code especially nowaday developers may not even compile
test the patch properly given how many arches we have here which will only waste
time on other people when things goes wrong.

Re: [PATCH] mm/vmscan: remove prefetch_prev_lru_page

[Qian Cai]

> On Jan 14, 2020, at 9:33 PM, Alex Shi <alex.shi@linux.alibaba.com> wrote:
> 
> 
> 
>> 在 2020/1/14 下午9:46, Qian Cai 写道:
>> 
>> 
>>>> On Jan 14, 2020, at 7:55 AM, Alex Shi <alex.shi@linux.alibaba.com> wrote:
>>> 
>>> This macro are never used in git history. So better to remove.
>> 
>> When removing unused thingy, it is important to figure out which commit introduced it in the first place and Cc the relevant people in that commit.
>> 
> 
> Thanks fore reminder, Qian!
> 
> This macro was introduced in 1da177e4c3f4 Linux-2.6.12-rc2, no author or commiter could be found.

Looks a bit deeper for this, and I am not sure if it is necessary to remove it especially this does not cause any complication warning noise, because the macro looks like a part of API design to have a pair of both read and write version, even though only the write version is used at the moment.

In theory,  there could be users for the read version in the future, and then it needs to be added back.

Re: [PATCH] mm/vmscan: remove prefetch_prev_lru_page

[Guoqing Jiang]

On 1/15/20 3:31 AM, Alex Shi wrote:
> 在 2020/1/14 下午9:46, Qian Cai 写道:
>>> On Jan 14, 2020, at 7:55 AM, Alex Shi <alex.shi@linux.alibaba.com> wrote:
>>>
>>> This macro are never used in git history. So better to remove.
>> When removing unused thingy, it is important to figure out which commit introduced it in the first place and Cc the relevant people in that commit.
>>
> Thanks fore reminder, Qian!
>
> This macro was introduced in 1da177e4c3f4 Linux-2.6.12-rc2, no author or commiter could be found.

FYI, seems it was introduced in commit 3aa1dc7725 [PATCH] multithread 
page reclaim in history tree.

Thanks,
Guoqing

Re: [PATCH] mm/vmscan: remove prefetch_prev_lru_page

[Andrew Morton]

On Thu, 16 Jan 2020 07:26:23 -0500 Qian Cai <cai@lca.pw> wrote:

> 
> 
> > On Jan 14, 2020, at 9:33 PM, Alex Shi <alex.shi@linux.alibaba.com> wrote:
> > 
> > 
> > 
> >> 在 2020/1/14 下午9:46, Qian Cai 写道:
> >> 
> >> 
> >>>> On Jan 14, 2020, at 7:55 AM, Alex Shi <alex.shi@linux.alibaba.com> wrote:
> >>> 
> >>> This macro are never used in git history. So better to remove.
> >> 
> >> When removing unused thingy, it is important to figure out which commit introduced it in the first place and Cc the relevant people in that commit.
> >> 
> > 
> > Thanks fore reminder, Qian!
> > 
> > This macro was introduced in 1da177e4c3f4 Linux-2.6.12-rc2, no author or commiter could be found.
> 
> Looks a bit deeper for this, and I am not sure if it is necessary to remove it especially this does not cause any complication warning noise, because the macro looks like a part of API design to have a pair of both read and write version, even though only the write version is used at the moment.
> 
> In theory,  there could be users for the read version in the future, and then it needs to be added back.

Sure.  A problem with leaving it in place is that this leads people to
assume it is tested, which it presumably is not.

I don't think there's any particular downside either way, really.  But
it's presently cruft so I'm inclined to remove it.  If someone has a
need then they can add it back (presumbly reimplement it, actually) and
test it then.