On Sun, Feb 14, 2021 at 4:23 PM David Howells wrote:
>
> Anyway, I have posted my fscache modernisation patches multiple times for
> public review, I have tried to involve the wider community in aspects of the
> development on public mailing lists and I have been including the maintainers
> in
Linus Torvalds wrote:
> But no, it's not a replacement for actual code review after the fact.
>
> If you think email has too long latency for review, and can't use
> public mailing lists and cc the people who are maintainers, then I
> simply don't want your patches.
I think we were talking at
On Thu, Feb 11, 2021 at 3:21 PM David Howells wrote:
>
> Most of the development discussion took place on IRC and waving snippets of
> code about in pastebin rather than email - the latency of email is just too
> high. There's not a great deal I can do about that now as I haven't kept IRC
>
On Thu, Feb 11, 2021 at 6:20 PM David Howells wrote:
>
> Linus Torvalds wrote:
>
> > Also, honestly, I really *REALLY* want your commit messages to talk
> > about who has been cc'd, who has been part of development, and point
> > to the PUBLIC MAILING LISTS WHERE THAT DISCUSSION WAS TAKING
Linus Torvalds wrote:
> Also, honestly, I really *REALLY* want your commit messages to talk
> about who has been cc'd, who has been part of development, and point
> to the PUBLIC MAILING LISTS WHERE THAT DISCUSSION WAS TAKING PLACE, so
> that I can actually see that "yes, other people were
Linus Torvalds wrote:
> ...
> IOW, I'm not against "wait_on_page_fscache()" as a function, but I
> *am* against the odd _mixing_ of things without a big explanation,
> where the code itself looks very odd and questionable.
>
> And I think the "fscache" waiting functions should not be visible to
On Wed, Feb 10, 2021 at 8:33 AM David Howells wrote:
>
> Then I could follow it up with this patch here, moving towards dropping the
> PG_fscache alias for the new API.
So I don't mind the alias per se, but I did mind the odd mixing of
names for the same thing.
So I think your change to make it
Linus Torvalds wrote:
> Does the code not hold a refcount already?
The attached patch will do that. Note that it's currently based on top of the
patch that drops the PG_fscache alias, so it refers to PG_private_2.
I've run all three patches through xfstests over afs, both with and without a
> Linus Torvalds wrote:
>
> > The PG_fscache bit waiting functions are completely crazy. The comment
> > about "this will wake up others" is actively wrong, and the waiting
> > function looks insane, because you're mixing the two names for
> > "fscache" which makes the code look totally
Linus Torvalds wrote:
> The PG_fscache bit waiting functions are completely crazy. The comment
> about "this will wake up others" is actively wrong, and the waiting
> function looks insane, because you're mixing the two names for
> "fscache" which makes the code look totally incomprehensible.
On Tue, Feb 9, 2021 at 2:07 PM Linus Torvalds
wrote:
>
> So I'm looking at this early, because I have more time now than I will
> have during the merge window, and honestly, your pull requests have
> been problematic in the past.
>
> The PG_fscache bit waiting functions are completely crazy. The
On Tue, Feb 9, 2021 at 12:21 PM Matthew Wilcox wrote:
>
> Yeah, I have trouble with the private2 vs fscache bit too. I've been
> trying to persuade David that he doesn't actually need an fscache
> bit at all; he can just increment the page's refcount to prevent it
> from being freed while he
Matthew Wilcox wrote:
> Yeah, I have trouble with the private2 vs fscache bit too. I've been
> trying to persuade David that he doesn't actually need an fscache
> bit at all; he can just increment the page's refcount to prevent it
> from being freed while he writes data to the cache.
That's
Linus Torvalds wrote:
> > Yeah, I have trouble with the private2 vs fscache bit too. I've been
> > trying to persuade David that he doesn't actually need an fscache
> > bit at all; he can just increment the page's refcount to prevent it
> > from being freed while he writes data to the cache.
>
Linus Torvalds wrote:
> The PG_fscache bit waiting functions are completely crazy. The comment
> about "this will wake up others" is actively wrong,
You mean this?
/**
* unlock_page_fscache - Unlock a page pinned with PG_fscache
* @page: The page
*
* Unlocks the page and wakes up sleepers
On Tue, Feb 09, 2021 at 11:06:41AM -0800, Linus Torvalds wrote:
> So I'm looking at this early, because I have more time now than I will
> have during the merge window, and honestly, your pull requests have
> been problematic in the past.
Thanks for looking at this early.
> The PG_fscache bit
On Tue, 2021-02-09 at 11:06 -0800, Linus Torvalds wrote:
> So I'm looking at this early, because I have more time now than I will
> have during the merge window, and honestly, your pull requests have
> been problematic in the past.
>
> The PG_fscache bit waiting functions are completely crazy.
So I'm looking at this early, because I have more time now than I will
have during the merge window, and honestly, your pull requests have
been problematic in the past.
The PG_fscache bit waiting functions are completely crazy. The comment
about "this will wake up others" is actively wrong, and
18 matches
Mail list logo