From: Andrew Morton <email@example.com> To: Mel Gorman <firstname.lastname@example.org> Cc: Jan Kara <email@example.com>, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org Subject: Re: [PATCH RFC] mm: migrate: Fix races of __find_get_block() and page migration Date: Fri, 12 Jul 2019 14:21:11 -0700 Message-ID: <email@example.com> (raw) In-Reply-To: <20190712123935.GK13484@suse.de> On Fri, 12 Jul 2019 13:39:35 +0100 Mel Gorman <firstname.lastname@example.org> wrote: > > So although I still think that just failing the migration if we cannot > > invalidate buffer heads is a safer choice, just extending the private_lock > > protected section does not seem as bad as I was afraid. > > > > That does not seem too bad and your revised patch looks functionally > fine. I'd leave out the tracepoints though because a perf probe would have > got roughly the same data and the tracepoint may be too specific to track > another class of problem. Whether the tracepoint survives or not and > with a changelog added; > > Acked-by: Mel Gorman <email@example.com> > > Andrew, which version do you want to go with, the original version or > this one that holds private_lock for slightly longer during migration? The revised version looks much more appealing for a -stable backport. I expect any mild performance issues can be address in the usual fashion. My main concern is not to put a large performance regression into mainline and stable kernels. How confident are we that this is (will be) sufficiently tested from that point of view?
next prev parent reply index Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-07-11 12:58 Jan Kara 2019-07-12 0:04 ` Andrew Morton 2019-07-12 8:04 ` Mel Gorman 2019-07-12 9:17 ` Jan Kara 2019-07-12 10:10 ` Mel Gorman 2019-07-12 11:20 ` Jan Kara 2019-07-12 12:39 ` Mel Gorman 2019-07-12 21:21 ` Andrew Morton [this message] 2019-07-14 21:20 ` Mel Gorman
Reply instructions: You may reply publically to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Linux-mm Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-mm/0 linux-mm/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-mm linux-mm/ https://lore.kernel.org/linux-mm \ email@example.com firstname.lastname@example.org public-inbox-index linux-mm Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kvack.linux-mm AGPL code for this site: git clone https://public-inbox.org/ public-inbox