Re: Kernel Benchmarking

[Sedat Dilek <sedat.dilek@gmail.com>]

On Fri, Sep 18, 2020 at 2:39 AM Sedat Dilek <sedat.dilek@gmail.com> wrote:
>
> On Thu, Sep 17, 2020 at 10:00 PM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > On Thu, Sep 17, 2020 at 12:27 PM Matthew Wilcox <willy@infradead.org> wrote:
> > >
> > > Ah, I see what you mean.  Hold the i_mmap_rwsem for write across,
> > > basically, the entirety of truncate_inode_pages_range().
> >
> > I really suspect that will be entirely unacceptable for latency
> > reasons, but who knows. In practice, nobody actually truncates a file
> > _while_ it's mapped, that's just crazy talk.
> >
> > But almost every time I go "nobody actually does this", I tend to be
> > surprised by just how crazy some loads are, and it turns out that
> > _somebody_ does it, and has a really good reason for doing odd things,
> > and has been doing it for years because it worked really well and
> > solved some odd problem.
> >
> > So the "hold it for the entirety of truncate_inode_pages_range()"
> > thing seems to be a really simple approach, and nice and clean, but it
> > makes me go "*somebody* is going to do bad things and complain about
> > page fault latencies".
> >
>
> Hi,
>
> I followed this thread a bit and see there is now a...
>
> commit 5ef64cc8987a9211d3f3667331ba3411a94ddc79
> "mm: allow a controlled amount of unfairness in the page lock"
>
> By first reading I saw...
>
> + *  (a) no special bits set:
> ...
> + *  (b) WQ_FLAG_EXCLUSIVE:
> ...
> + *  (b) WQ_FLAG_EXCLUSIVE | WQ_FLAG_CUSTOM:
>
> The last one should be (c).
>
> There was a second typo I cannot remember when you sent your patch
> without a commit message.
>
> Will look again.
>
> Thanks and Greetings,
> - Sedat -

Ah I see...

+ * we have multiple different kinds of waits, not just he usual "exclusive"

... *t*he usual ...

- Sedat -