Re: [RFC PATCH 4/8] mm/madvise: define madvise behavior in a struct

[Nadav Amit]

> On Sep 27, 2021, at 2:31 AM, Kirill A. Shutemov <kirill@xxxxxxxxxxxxx> wrote:
> 
> On Sun, Sep 26, 2021 at 09:12:55AM -0700, Nadav Amit wrote:
>> From: Nadav Amit <namit@xxxxxxxxxx>
>> 
>> The different behaviors of madvise are different in several ways, which
>> are distributed across several functions. Use the design pattern from
>> iouring in order to define the actions that are required for each
>> behavior.
>> 
>> The next patches will get rid of old helper functions that are modified
>> in this patch and the redundant use of array_index_nospec(). The next
>> patches will add more actions for each leaf into the new struct.
>> 
>> No functional change is intended.
>> 
>> Cc: Andrea Arcangeli <aarcange@xxxxxxxxxx>
>> Cc: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
>> Cc: Minchan Kim <minchan@xxxxxxxxxx>
>> Cc: Colin Cross <ccross@xxxxxxxxxx>
>> Cc: Suren Baghdasarya <surenb@xxxxxxxxxx>
>> Cc: Mike Rapoport <rppt@xxxxxxxxxxxxxxxxxx>
>> Signed-off-by: Nadav Amit <namit@xxxxxxxxxx>
>> ---
>> mm/madvise.c | 168 +++++++++++++++++++++++++++++++++------------------
>> 1 file changed, 109 insertions(+), 59 deletions(-)
>> 
>> diff --git a/mm/madvise.c b/mm/madvise.c
>> index 17e39c70704b..127507c71ba9 100644
>> --- a/mm/madvise.c
>> +++ b/mm/madvise.c
>> @@ -29,6 +29,7 @@
>> #include <linux/swapops.h>
>> #include <linux/shmem_fs.h>
>> #include <linux/mmu_notifier.h>
>> +#include <linux/nospec.h>
>> 
>> #include <asm/tlb.h>
>> 
>> @@ -39,6 +40,101 @@ struct madvise_walk_private {
>> 	bool pageout;
>> };
>> 
>> +struct madvise_info {
>> +	u8 behavior_valid: 1;
>> +	u8 process_behavior_valid: 1;
>> +	u8 need_mmap_read_only: 1;
>> +};
>> +
>> +static const struct madvise_info madvise_info[MADV_SOFT_OFFLINE+1] = {
> 
> MADV_SOFT_OFFLINE+1 smells bad.

I can set another constant instead and let the compiler shout if anything
outside the array is initialized.

> 
> And I don't like the change in general. Given that MADV_SOFT_OFFLINE is
> 101, the array will be mostly empty.

Seriously, these is less than 128B - two cachelines. Perhaps they should
be aligned. But this whole change should have no effect on code/data size.

> 
> I donno. I don't see any improvement with the patch. But maybe it's only me.

The following patches make it clearer when TLBs flushes are batched and
when mmap_lock is not taken (which is by the way not clear from the code).

I could have added two more functions for that and it would have taken
me less time. I do not think the end result of having ~5 different
functions to figure out the actions needed for each behavior would be
as clear.