lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 18 Sep 2020 22:25:36 +0200
From:   Sedat Dilek <sedat.dilek@...il.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Matthew Wilcox <willy@...radead.org>,
        Michael Larabel <Michael@...haellarabel.com>,
        Matthieu Baerts <matthieu.baerts@...sares.net>,
        Amir Goldstein <amir73il@...il.com>,
        "Ted Ts'o" <tytso@...gle.com>,
        Andreas Dilger <adilger.kernel@...ger.ca>,
        Ext4 Developers List <linux-ext4@...r.kernel.org>,
        Jan Kara <jack@...e.cz>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: Kernel Benchmarking

On Fri, Sep 18, 2020 at 2:40 AM Sedat Dilek <sedat.dilek@...il.com> wrote:
>
> On Fri, Sep 18, 2020 at 2:39 AM Sedat Dilek <sedat.dilek@...il.com> wrote:
> >
> > On Thu, Sep 17, 2020 at 10:00 PM Linus Torvalds
> > <torvalds@...ux-foundation.org> wrote:
> > >
> > > On Thu, Sep 17, 2020 at 12:27 PM Matthew Wilcox <willy@...radead.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 ...
>

Hi Linus,

do you want me to send a patch for the above typos or do you want to
do that yourself?

Thanks.

Regards,
- Sedat -

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ