On Fri, Sep 18, 2020 at 2:39 AM Sedat Dilek <sedat.dilek@xxxxxxxxx> wrote: > > On Thu, Sep 17, 2020 at 10:00 PM Linus Torvalds > <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > > > On Thu, Sep 17, 2020 at 12:27 PM Matthew Wilcox <willy@xxxxxxxxxxxxx> 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 -