Received-SPF: pass (google.com: domain of linux-kernel+bounces-197280-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Precedence: bulk
MIME-Version: 1.0
References: <20240531092001.30428-1-byungchul@sk.com> <20240531092001.30428-10-byungchul@sk.com>
 <fab1dd64-c652-4160-93b4-7b483a8874da@intel.com>
In-Reply-To: <fab1dd64-c652-4160-93b4-7b483a8874da@intel.com>
From: Byungchul Park <lkml.byungchul.park@gmail.com>
Date: Sat, 1 Jun 2024 03:04:24 +0900
Message-ID: <CAHyrMpxETdVewTH3MCS4qPyD6Xf1zRUfWZf-8SCdpCFj2Pj_Wg@mail.gmail.com>
Subject: Re: [PATCH v11 09/12] mm: implement LUF(Lazy Unmap Flush) defering
 tlb flush when folios get unmapped
To: Dave Hansen <dave.hansen@intel.com>
Cc: Byungchul Park <byungchul@sk.com>, linux-kernel@vger.kernel.org, linux-mm@kvack.org, 
	kernel_team@skhynix.com, akpm@linux-foundation.org, ying.huang@intel.com, 
	vernhao@tencent.com, mgorman@techsingularity.net, hughd@google.com, 
	willy@infradead.org, david@redhat.com, peterz@infradead.org, luto@kernel.org, 
	tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, 
	dave.hansen@linux.intel.com, rjgolo@gmail.com
Content-Type: text/plain; charset="UTF-8"

Dave Hansen <dave.hansen@intel.com> wrote:
>
> On 5/31/24 02:19, Byungchul Park wrote:
> ..
> > diff --git a/include/linux/fs.h b/include/linux/fs.h
> > index 0283cf366c2a..03683bf66031 100644
> > --- a/include/linux/fs.h
> > +++ b/include/linux/fs.h
> > @@ -2872,6 +2872,12 @@ static inline void file_end_write(struct file *file)
> >       if (!S_ISREG(file_inode(file)->i_mode))
> >               return;
> >       sb_end_write(file_inode(file)->i_sb);
> > +
> > +     /*
> > +      * XXX: If needed, can be optimized by avoiding luf_flush() if
> > +      * the address space of the file has never been involved by luf.
> > +      */
> > +     luf_flush();
> >  }
> ..
> > +void luf_flush(void)
> > +{
> > +     unsigned long flags;
> > +     unsigned short int ugen;
> > +
> > +     /*
> > +      * Obtain the latest ugen number.
> > +      */
> > +     spin_lock_irqsave(&luf_lock, flags);
> > +     ugen = luf_gen;
> > +     spin_unlock_irqrestore(&luf_lock, flags);
> > +
> > +     check_luf_flush(ugen);
> > +}
>
> Am I reading this right?  There's now an unconditional global spinlock

It looked *too much* to split the lock to several locks as rcu does until
version 11.  However, this code introduced in v11 looks problematic.

> acquired in the sys_write() path?  How can this possibly scale?

I should find a better way.

> So, yeah, I think an optimization is absolutely needed.  But, on a more
> fundamental level, I just don't believe these patches are being tested.
> Even a simple microbenchmark should show a pretty nasty regression on
> any decently large system:
>
> > https://github.com/antonblanchard/will-it-scale/blob/master/tests/write1.c
>
> Second, I was just pointing out sys_write() as an example of how the
> page cache could change.  Couldn't a separate, read/write mmap() of the
> file do the same thing and *not* go through sb_end_write()?
>
> So:
>
>         fd = open("foo");
>         ptr1 = mmap(fd, PROT_READ);
>         ptr2 = mmap(fd, PROT_READ|PROT_WRITE);
>
>         foo = *ptr1; // populate the page cache
>         ... page cache page is reclaimed and LUF'd
>         *ptr2 = bar; // new page cache page is allocated and written to

I think this part would work but I'm not convinced.  I will check again.

>         printk("*ptr1: %d\n", *ptr1);
>
> Doesn't the printk() see stale data?
>
> I think tglx would call all of this "tinkering".  The approach to this
> series is to "fix" narrow, specific cases that reviewers point out, make
> it compile, then send it out again, hoping someone will apply it.

Sorry for not perfect work and bothering you but you know what?  I
can see what is happening in this community too.  Of course, I bet
you would post better quality mm patches from the 1st version than
me but might not in other subsystems.

> So, for me, until the approach to this series changes: NAK, for x86.

I understand why you got mad and feel sorry but I couldn't expect
the regression you mentioned above.  And I admit the patches have
had problems I couldn't find in advance until you, Hildenbrand and
Ying.  I will do better.

> Andrew, please don't take this series.  Or, if you do, please drop the
> patch enabling it on x86.

I don't want to ask to merge either, if there are still issues.

> I also have the feeling our VFS friends won't take kindly to having

That is also what I thought it was.  What should I do then?
I don't believe you do not agree with the concept itself.  Thing is
the current version is not good enough.  I will do my best by doing
what I can do.

> random luf_foo() hooks in their hot paths, optimized or not.  I don't
> see any of them on cc.

Yes.  I should've cc'd them.  I will.

        Byungchul